mustrd 0.3.1a10__tar.gz → 0.3.3__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {mustrd-0.3.1a10 → mustrd-0.3.3}/PKG-INFO +79 -16
- mustrd-0.3.3/README.md +117 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/mustrdAnzo.py +15 -6
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/spec_component.py +1 -1
- {mustrd-0.3.1a10 → mustrd-0.3.3}/pyproject.toml +1 -1
- mustrd-0.3.1a10/README.md +0 -54
- {mustrd-0.3.1a10 → mustrd-0.3.3}/LICENSE +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/README.adoc +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/README.md +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/TestResult.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/__init__.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/anzo_utils.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/logger_setup.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/catalog-v001.xml +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/mustrdShapes.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/mustrdTestOntology.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/mustrdTestShapes.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/ontology.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/test-resources/resources.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/triplestoreOntology.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/model/triplestoreshapes.ttl +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/mustrd.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/mustrdGraphDb.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/mustrdRdfLib.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/mustrdTestPlugin.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/namespace.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/run.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/steprunner.py +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/templates/md_ResultList_leaf_template.jinja +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/templates/md_ResultList_template.jinja +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/templates/md_stats_template.jinja +0 -0
- {mustrd-0.3.1a10 → mustrd-0.3.3}/mustrd/utils.py +0 -0
@@ -1,6 +1,6 @@
|
|
1
1
|
Metadata-Version: 2.3
|
2
2
|
Name: mustrd
|
3
|
-
Version: 0.3.
|
3
|
+
Version: 0.3.3
|
4
4
|
Summary: A Spec By Example framework for RDF and SPARQL, Inspired by Cucumber.
|
5
5
|
License: MIT
|
6
6
|
Author: John Placek
|
@@ -34,13 +34,13 @@ Requires-Dist: urllib3 (==1.26.19)
|
|
34
34
|
Project-URL: Repository, https://github.com/Semantic-partners/mustrd
|
35
35
|
Description-Content-Type: text/markdown
|
36
36
|
|
37
|
-
#
|
37
|
+
# MustRD
|
38
38
|
|
39
39
|
**"MustRD: Validate your SPARQL queries and transformations with precision and confidence, using BDD and Given-When-Then principles."**
|
40
40
|
|
41
|
-
[
|
41
|
+
[](https://github.com/Semantic-partners/mustrd/tree/python-coverage-comment-action-data)
|
42
42
|
|
43
|
-
|
43
|
+
## Why?
|
44
44
|
|
45
45
|
SPARQL is a powerful query language for RDF data, but how can you ensure your queries and transformations are doing what you intend? Whether you're working on a pipeline or a standalone query, certainty is key.
|
46
46
|
|
@@ -48,11 +48,11 @@ While RDF and SPARQL offer great flexibility, we noticed a gap in tooling to val
|
|
48
48
|
|
49
49
|
With MustRD, you can:
|
50
50
|
|
51
|
-
|
52
|
-
|
53
|
-
|
51
|
+
- Define data scenarios and verify that queries produce the expected results.
|
52
|
+
- Test edge cases to ensure your queries remain reliable.
|
53
|
+
- Isolate small SPARQL enrichment or transformation steps and confirm you're only inserting what you intend.
|
54
54
|
|
55
|
-
|
55
|
+
## What?
|
56
56
|
|
57
57
|
MustRD is a Spec-By-Example ontology with a reference Python implementation, inspired by tools like Cucumber. It uses the Given-When-Then approach to define and validate SPARQL queries and transformations.
|
58
58
|
|
@@ -62,23 +62,85 @@ MustRD is designed to be triplestore/SPARQL engine agnostic, leveraging open sta
|
|
62
62
|
|
63
63
|
MustRD is not an alternative to SHACL. While SHACL validates data structures, MustRD focuses on validating data transformations and query results.
|
64
64
|
|
65
|
-
|
65
|
+
## How?
|
66
66
|
|
67
67
|
You define your specs in Turtle (`.ttl`) or TriG (`.trig`) files using the Given-When-Then approach:
|
68
68
|
|
69
|
-
|
70
|
-
|
71
|
-
|
69
|
+
- **Given**: Define the starting dataset.
|
70
|
+
- **When**: Specify the action (e.g., a SPARQL query).
|
71
|
+
- **Then**: Outline the expected results.
|
72
72
|
|
73
73
|
Depending on the type of SPARQL query (CONSTRUCT, SELECT, INSERT/DELETE), MustRD runs the query and compares the results against the expectations defined in the spec.
|
74
74
|
|
75
75
|
Expectations can also be defined as:
|
76
76
|
|
77
|
-
|
78
|
-
|
79
|
-
|
77
|
+
- INSERT queries.
|
78
|
+
- SELECT queries.
|
79
|
+
- Higher-order expectation languages, similar to those used in various platforms.
|
80
80
|
|
81
|
-
|
81
|
+
## Example
|
82
|
+
|
83
|
+
### Configuration File
|
84
|
+
|
85
|
+
You'll have a configuration `.ttl` file, which acts as a suite of tests. It tells MustRD where to look for test specifications and any triplestore configurations you might have:
|
86
|
+
|
87
|
+
```ttl
|
88
|
+
:test_example a :MustrdTest;
|
89
|
+
:hasSpecPath "test/specs/";
|
90
|
+
:hasDataPath "test/data/";
|
91
|
+
:hasPytestPath "example";
|
92
|
+
:triplestoreSpecPath "test/triplestore_config/triplestores.ttl";
|
93
|
+
:filterOnTripleStore triplestore:example_test .
|
94
|
+
```
|
95
|
+
|
96
|
+
### Test Specification
|
97
|
+
|
98
|
+
In the directory specified by `:hasSpecPath`, you'll have one or more `.mustrd.ttl` files. These can be organized in a directory structure. MustRD collects them and reports results to your test runner.
|
99
|
+
|
100
|
+
```ttl
|
101
|
+
:test_example :given [ a :FileDataset ;
|
102
|
+
:file "test/data/given.ttl" ] ;
|
103
|
+
:when [ a :TextSparqlSource ;
|
104
|
+
:queryText "SELECT ?s ?p ?o WHERE { ?s ?p ?o }" ;
|
105
|
+
:queryType :SelectSparql ] ;
|
106
|
+
:then [ a :OrderedTableDataset ;
|
107
|
+
:hasRow [ :variable "s" ; :boundValue "example:subject" ;
|
108
|
+
:variable "p" ; :boundValue "example:predicate" ;
|
109
|
+
:variable "o" ; :boundValue "example:object" ] ].
|
110
|
+
```
|
111
|
+
|
112
|
+
And you will have a `'test/data/given.ttl'` which contains the given ttl.
|
113
|
+
|
114
|
+
```ttl
|
115
|
+
example:subject example:predicate example:object .
|
116
|
+
```
|
117
|
+
|
118
|
+
### Running Tests
|
119
|
+
|
120
|
+
Run the test using the MustRD Pytest plugin:
|
121
|
+
|
122
|
+
```bash
|
123
|
+
poetry run pytest --mustrd --config=test/mustrd_configuration.ttl --md=render/github_job_summary.md
|
124
|
+
```
|
125
|
+
|
126
|
+
This will validate your SPARQL queries against the defined dataset and expected results, ensuring your transformations behave as intended.
|
127
|
+
|
128
|
+
You can refer to SPARQL inline, in files, or in Anzo Graphmarts, Steps, or Layers. See `GETSTARTED.adoc` for more details.
|
129
|
+
|
130
|
+
#### Integrating with Visual Studio Code (vscode)
|
131
|
+
We have a pytest plugin.
|
132
|
+
1. Choose a python interpreter (probably a venv)
|
133
|
+
2. `pip install mustrd ` in it.
|
134
|
+
3. add to your settings.json
|
135
|
+
```json
|
136
|
+
"python.testing.pytestArgs": [
|
137
|
+
"--mustrd", "--md=junit/github_job_summary.md", "--config=test/test_config_local.ttl"
|
138
|
+
],
|
139
|
+
```
|
140
|
+
4. VS Code should auto discover your tests and they'll show up in the flask icon 'tab'.
|
141
|
+

|
142
|
+
|
143
|
+
## When?
|
82
144
|
|
83
145
|
MustRD is a work in progress, built to meet the needs of our projects across multiple clients and vendor stacks. While we find it useful, it may not meet your needs out of the box.
|
84
146
|
|
@@ -89,3 +151,4 @@ We invite you to try it, raise issues, or contribute via pull requests. If you n
|
|
89
151
|
Semantic Partners is a specialist consultancy in Semantic Technology. If you need more support, contact us at info@semanticpartners.com or mustrd@semanticpartners.com.
|
90
152
|
|
91
153
|
|
154
|
+
|
mustrd-0.3.3/README.md
ADDED
@@ -0,0 +1,117 @@
|
|
1
|
+
# MustRD
|
2
|
+
|
3
|
+
**"MustRD: Validate your SPARQL queries and transformations with precision and confidence, using BDD and Given-When-Then principles."**
|
4
|
+
|
5
|
+
[](https://github.com/Semantic-partners/mustrd/tree/python-coverage-comment-action-data)
|
6
|
+
|
7
|
+
## Why?
|
8
|
+
|
9
|
+
SPARQL is a powerful query language for RDF data, but how can you ensure your queries and transformations are doing what you intend? Whether you're working on a pipeline or a standalone query, certainty is key.
|
10
|
+
|
11
|
+
While RDF and SPARQL offer great flexibility, we noticed a gap in tooling to validate their behavior. We missed the robust testing frameworks available in imperative programming languages that help ensure your code works as expected.
|
12
|
+
|
13
|
+
With MustRD, you can:
|
14
|
+
|
15
|
+
- Define data scenarios and verify that queries produce the expected results.
|
16
|
+
- Test edge cases to ensure your queries remain reliable.
|
17
|
+
- Isolate small SPARQL enrichment or transformation steps and confirm you're only inserting what you intend.
|
18
|
+
|
19
|
+
## What?
|
20
|
+
|
21
|
+
MustRD is a Spec-By-Example ontology with a reference Python implementation, inspired by tools like Cucumber. It uses the Given-When-Then approach to define and validate SPARQL queries and transformations.
|
22
|
+
|
23
|
+
MustRD is designed to be triplestore/SPARQL engine agnostic, leveraging open standards to ensure compatibility across different platforms.
|
24
|
+
|
25
|
+
### What it is NOT
|
26
|
+
|
27
|
+
MustRD is not an alternative to SHACL. While SHACL validates data structures, MustRD focuses on validating data transformations and query results.
|
28
|
+
|
29
|
+
## How?
|
30
|
+
|
31
|
+
You define your specs in Turtle (`.ttl`) or TriG (`.trig`) files using the Given-When-Then approach:
|
32
|
+
|
33
|
+
- **Given**: Define the starting dataset.
|
34
|
+
- **When**: Specify the action (e.g., a SPARQL query).
|
35
|
+
- **Then**: Outline the expected results.
|
36
|
+
|
37
|
+
Depending on the type of SPARQL query (CONSTRUCT, SELECT, INSERT/DELETE), MustRD runs the query and compares the results against the expectations defined in the spec.
|
38
|
+
|
39
|
+
Expectations can also be defined as:
|
40
|
+
|
41
|
+
- INSERT queries.
|
42
|
+
- SELECT queries.
|
43
|
+
- Higher-order expectation languages, similar to those used in various platforms.
|
44
|
+
|
45
|
+
## Example
|
46
|
+
|
47
|
+
### Configuration File
|
48
|
+
|
49
|
+
You'll have a configuration `.ttl` file, which acts as a suite of tests. It tells MustRD where to look for test specifications and any triplestore configurations you might have:
|
50
|
+
|
51
|
+
```ttl
|
52
|
+
:test_example a :MustrdTest;
|
53
|
+
:hasSpecPath "test/specs/";
|
54
|
+
:hasDataPath "test/data/";
|
55
|
+
:hasPytestPath "example";
|
56
|
+
:triplestoreSpecPath "test/triplestore_config/triplestores.ttl";
|
57
|
+
:filterOnTripleStore triplestore:example_test .
|
58
|
+
```
|
59
|
+
|
60
|
+
### Test Specification
|
61
|
+
|
62
|
+
In the directory specified by `:hasSpecPath`, you'll have one or more `.mustrd.ttl` files. These can be organized in a directory structure. MustRD collects them and reports results to your test runner.
|
63
|
+
|
64
|
+
```ttl
|
65
|
+
:test_example :given [ a :FileDataset ;
|
66
|
+
:file "test/data/given.ttl" ] ;
|
67
|
+
:when [ a :TextSparqlSource ;
|
68
|
+
:queryText "SELECT ?s ?p ?o WHERE { ?s ?p ?o }" ;
|
69
|
+
:queryType :SelectSparql ] ;
|
70
|
+
:then [ a :OrderedTableDataset ;
|
71
|
+
:hasRow [ :variable "s" ; :boundValue "example:subject" ;
|
72
|
+
:variable "p" ; :boundValue "example:predicate" ;
|
73
|
+
:variable "o" ; :boundValue "example:object" ] ].
|
74
|
+
```
|
75
|
+
|
76
|
+
And you will have a `'test/data/given.ttl'` which contains the given ttl.
|
77
|
+
|
78
|
+
```ttl
|
79
|
+
example:subject example:predicate example:object .
|
80
|
+
```
|
81
|
+
|
82
|
+
### Running Tests
|
83
|
+
|
84
|
+
Run the test using the MustRD Pytest plugin:
|
85
|
+
|
86
|
+
```bash
|
87
|
+
poetry run pytest --mustrd --config=test/mustrd_configuration.ttl --md=render/github_job_summary.md
|
88
|
+
```
|
89
|
+
|
90
|
+
This will validate your SPARQL queries against the defined dataset and expected results, ensuring your transformations behave as intended.
|
91
|
+
|
92
|
+
You can refer to SPARQL inline, in files, or in Anzo Graphmarts, Steps, or Layers. See `GETSTARTED.adoc` for more details.
|
93
|
+
|
94
|
+
#### Integrating with Visual Studio Code (vscode)
|
95
|
+
We have a pytest plugin.
|
96
|
+
1. Choose a python interpreter (probably a venv)
|
97
|
+
2. `pip install mustrd ` in it.
|
98
|
+
3. add to your settings.json
|
99
|
+
```json
|
100
|
+
"python.testing.pytestArgs": [
|
101
|
+
"--mustrd", "--md=junit/github_job_summary.md", "--config=test/test_config_local.ttl"
|
102
|
+
],
|
103
|
+
```
|
104
|
+
4. VS Code should auto discover your tests and they'll show up in the flask icon 'tab'.
|
105
|
+

|
106
|
+
|
107
|
+
## When?
|
108
|
+
|
109
|
+
MustRD is a work in progress, built to meet the needs of our projects across multiple clients and vendor stacks. While we find it useful, it may not meet your needs out of the box.
|
110
|
+
|
111
|
+
We invite you to try it, raise issues, or contribute via pull requests. If you need custom features, contact us for consultancy rates, and we may prioritize your request.
|
112
|
+
|
113
|
+
## Support
|
114
|
+
|
115
|
+
Semantic Partners is a specialist consultancy in Semantic Technology. If you need more support, contact us at info@semanticpartners.com or mustrd@semanticpartners.com.
|
116
|
+
|
117
|
+
|
@@ -98,8 +98,11 @@ def get_query_from_step(triple_store: dict, query_step_uri: URIRef) -> str:
|
|
98
98
|
?stepUri a <http://cambridgesemantics.com/ontologies/Graphmarts#Step>;
|
99
99
|
<http://cambridgesemantics.com/ontologies/Graphmarts#transformQuery> ?query
|
100
100
|
}}"""
|
101
|
-
|
102
|
-
|
101
|
+
result = json_to_dictlist(query_configuration(anzo_config=triple_store, query=query))
|
102
|
+
if len(result) == 0:
|
103
|
+
raise FileNotFoundError(
|
104
|
+
f"Querynot found for step {query_step_uri}")
|
105
|
+
return result[0].get("query")
|
103
106
|
|
104
107
|
def get_queries_from_templated_step(triple_store: dict, query_step_uri: URIRef) -> dict:
|
105
108
|
query = f"""SELECT ?param_query ?query_template WHERE {{
|
@@ -109,8 +112,11 @@ def get_queries_from_templated_step(triple_store: dict, query_step_uri: URIRef)
|
|
109
112
|
<http://cambridgesemantics.com/ontologies/Graphmarts#template> ?query_template .
|
110
113
|
}}
|
111
114
|
"""
|
112
|
-
|
113
|
-
|
115
|
+
result = json_to_dictlist(query_configuration(anzo_config=triple_store, query=query))
|
116
|
+
if len(result) == 0:
|
117
|
+
raise FileNotFoundError(
|
118
|
+
f"Templated query not found for {query_step_uri}")
|
119
|
+
return result[0]
|
114
120
|
|
115
121
|
def get_queries_for_layer(triple_store: dict, graphmart_layer_uri: URIRef):
|
116
122
|
query = f"""PREFIX graphmarts: <http://cambridgesemantics.com/ontologies/Graphmarts#>
|
@@ -129,8 +135,11 @@ SELECT ?query ?param_query ?query_template
|
|
129
135
|
. }}
|
130
136
|
}}
|
131
137
|
ORDER BY ?index"""
|
132
|
-
|
133
|
-
|
138
|
+
result = json_to_dictlist(query_configuration(anzo_config=triple_store, query=query))
|
139
|
+
if len(result) == 0:
|
140
|
+
raise FileNotFoundError(
|
141
|
+
f"Queries not found for graphmart layer {graphmart_layer_uri}")
|
142
|
+
return result
|
134
143
|
|
135
144
|
def upload_given(triple_store: dict, given: Graph):
|
136
145
|
logging.debug(f"upload_given {triple_store} {given}")
|
@@ -675,7 +675,7 @@ def get_spec_component_from_file(path: Path) -> str:
|
|
675
675
|
raise ValueError(f"Path {path} is a directory, expected a file")
|
676
676
|
|
677
677
|
try:
|
678
|
-
content = path.read_text()
|
678
|
+
content = path.read_text(encoding='utf-8')
|
679
679
|
except FileNotFoundError:
|
680
680
|
raise
|
681
681
|
return str(content)
|
mustrd-0.3.1a10/README.md
DELETED
@@ -1,54 +0,0 @@
|
|
1
|
-
# mustrd
|
2
|
-
|
3
|
-
**"MustRD: Validate your SPARQL queries and transformations with precision and confidence, using BDD and Given-When-Then principles."**
|
4
|
-
|
5
|
-
[<img src="https://github.com/Semantic-partners/mustrd/raw/python-coverage-comment-action-data/badge.svg?sanitize=true" alt="coverage badge">](https://github.com/Semantic-partners/mustrd/tree/python-coverage-comment-action-data)
|
6
|
-
|
7
|
-
### Why?
|
8
|
-
|
9
|
-
SPARQL is a powerful query language for RDF data, but how can you ensure your queries and transformations are doing what you intend? Whether you're working on a pipeline or a standalone query, certainty is key.
|
10
|
-
|
11
|
-
While RDF and SPARQL offer great flexibility, we noticed a gap in tooling to validate their behavior. We missed the robust testing frameworks available in imperative programming languages that help ensure your code works as expected.
|
12
|
-
|
13
|
-
With MustRD, you can:
|
14
|
-
|
15
|
-
* Define data scenarios and verify that queries produce the expected results.
|
16
|
-
* Test edge cases to ensure your queries remain reliable.
|
17
|
-
* Isolate small SPARQL enrichment or transformation steps and confirm you're only inserting what you intend.
|
18
|
-
|
19
|
-
### What?
|
20
|
-
|
21
|
-
MustRD is a Spec-By-Example ontology with a reference Python implementation, inspired by tools like Cucumber. It uses the Given-When-Then approach to define and validate SPARQL queries and transformations.
|
22
|
-
|
23
|
-
MustRD is designed to be triplestore/SPARQL engine agnostic, leveraging open standards to ensure compatibility across different platforms.
|
24
|
-
|
25
|
-
### What it is NOT
|
26
|
-
|
27
|
-
MustRD is not an alternative to SHACL. While SHACL validates data structures, MustRD focuses on validating data transformations and query results.
|
28
|
-
|
29
|
-
### How?
|
30
|
-
|
31
|
-
You define your specs in Turtle (`.ttl`) or TriG (`.trig`) files using the Given-When-Then approach:
|
32
|
-
|
33
|
-
* **Given**: Define the starting dataset.
|
34
|
-
* **When**: Specify the action (e.g., a SPARQL query).
|
35
|
-
* **Then**: Outline the expected results.
|
36
|
-
|
37
|
-
Depending on the type of SPARQL query (CONSTRUCT, SELECT, INSERT/DELETE), MustRD runs the query and compares the results against the expectations defined in the spec.
|
38
|
-
|
39
|
-
Expectations can also be defined as:
|
40
|
-
|
41
|
-
* INSERT queries.
|
42
|
-
* SELECT queries.
|
43
|
-
* Higher-order expectation languages, similar to those used in various platforms.
|
44
|
-
|
45
|
-
### When?
|
46
|
-
|
47
|
-
MustRD is a work in progress, built to meet the needs of our projects across multiple clients and vendor stacks. While we find it useful, it may not meet your needs out of the box.
|
48
|
-
|
49
|
-
We invite you to try it, raise issues, or contribute via pull requests. If you need custom features, contact us for consultancy rates, and we may prioritize your request.
|
50
|
-
|
51
|
-
## Support
|
52
|
-
|
53
|
-
Semantic Partners is a specialist consultancy in Semantic Technology. If you need more support, contact us at info@semanticpartners.com or mustrd@semanticpartners.com.
|
54
|
-
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|
File without changes
|