Initial support for fetching embedded SHACL info in OWL #34
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Support fetching domain, range and cardinality information from
vocabularies containing a SHACL graph. The queries are different
depending on whether it is an object property or a datatype property.
Where the information isn't available, there will be empty cells in the
report.
There is also support for value node constraints for certain patterns of
expressing ranges for IRIs with `sh:hasValue`, such as SKOS
vocabularies, used for example in recent versions of the eProcurement
ontology (ePO):
```ttl
sh:nodeKind sh:IRI ;
sh:node [
rdf:type sh:NodeShape ;
sh:property [
sh:path skos:inScheme ;
sh:hasValue atold:language ;
] ;
] .
```
Currently, this feature is NOT for capturing changes in the domain,
range and cardinality, and is only for the case of ADDED instances of
such resources, not their modifications.
The information won't show up for individual property changes on the
resources (added/updated/changed/moved labels and the whole shebang).
The queries in those cases will differ between modification types, and
there is the question of how to fit all of the information in an
already-crowded table. Work will continue on how best to approach this.
P.S: There are nested OPTIONALs as the graph may not exist, so
performance may be affected, though hopefully not by too much. If that
becomes a concern, we can turn these over onto a new template, where a
SHACL graph would be made mandatory.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report. There is also support for value node constraints for certain patterns of expressing ranges for IRIs with `sh:hasValue`, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO): ```ttl sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] . ``` Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications. The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this. P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory. Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report. There is also support for value node constraints for certain patterns of expressing ranges for IRIs with `sh:hasValue`, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO): ```ttl sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] . ``` Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications. The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this. P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory. Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report. There is also support for value node constraints for certain patterns of expressing ranges for IRIs with `sh:hasValue`, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO): ```ttl sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] . ``` Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications. The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this. P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory. Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report. There is also support for value node constraints for certain patterns of expressing ranges for IRIs with `sh:hasValue`, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO): ```ttl sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] . ``` Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications. The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this. P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory. Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report. There is also support for value node constraints for certain patterns of expressing ranges for IRIs with `sh:hasValue`, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO): ```ttl sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] . ``` Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications. The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this. P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory. Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 11, 2025
Support fetching domain, range and cardinality information from
vocabularies containing a SHACL graph. The queries are different
depending on whether it is an object property or a datatype property.
Where the information isn't available, there will be empty cells in the
report.
There is also support for value node constraints for certain patterns of
expressing ranges for IRIs with `sh:hasValue`, such as SKOS
vocabularies, used for example in recent versions of the eProcurement
ontology (ePO):
```ttl
sh:nodeKind sh:IRI ;
sh:node [
rdf:type sh:NodeShape ;
sh:property [
sh:path skos:inScheme ;
sh:hasValue atold:language ;
] ;
] .
```
Currently, this feature is NOT for capturing changes in the domain,
range and cardinality, and is only for the case of ADDED instances of
such resources, not their modifications.
The information won't show up for individual property changes on the
resources (added/updated/changed/moved labels and the whole shebang).
The queries in those cases will differ between modification types, and
there is the question of how to fit all of the information in an
already-crowded table. Work will continue on how best to approach this.
P.S: There are nested OPTIONALs as the graph may not exist, so
performance may be affected, though hopefully not by too much. If that
becomes a concern, we can turn these over onto a new template, where a
SHACL graph would be made mandatory.
Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 12, 2025
Support fetching domain, range and cardinality information from
vocabularies containing a SHACL graph. The queries are different
depending on whether it is an object property or a datatype property.
Where the information isn't available, there will be empty cells in the
report.
There is also support for value node constraints for certain patterns of
expressing ranges for IRIs with `sh:hasValue`, such as SKOS
vocabularies, used for example in recent versions of the eProcurement
ontology (ePO):
```ttl
sh:nodeKind sh:IRI ;
sh:node [
rdf:type sh:NodeShape ;
sh:property [
sh:path skos:inScheme ;
sh:hasValue atold:language ;
] ;
] .
```
Currently, this feature is NOT for capturing changes in the domain,
range and cardinality, and is only for the case of ADDED instances of
such resources, not their modifications.
The information won't show up for individual property changes on the
resources (added/updated/changed/moved labels and the whole shebang).
The queries in those cases will differ between modification types, and
there is the question of how to fit all of the information in an
already-crowded table. Work will continue on how best to approach this.
P.S: There are nested OPTIONALs as the graph may not exist, so
performance may be affected, though hopefully not by too much. If that
becomes a concern, we can turn these over onto a new template, where a
SHACL graph would be made mandatory.
Application of meaningfy-ws/diff-query-generator#34.
schivmeister
added a commit
to meaningfy-ws/rdf-differ-ws
that referenced
this pull request
Nov 12, 2025
Support fetching domain, range and cardinality information from
vocabularies containing a SHACL graph. The queries are different
depending on whether it is an object property or a datatype property.
Where the information isn't available, there will be empty cells in the
report.
There is also support for value node constraints for certain patterns of
expressing ranges for IRIs with `sh:hasValue`, such as SKOS
vocabularies, used for example in recent versions of the eProcurement
ontology (ePO):
```ttl
sh:nodeKind sh:IRI ;
sh:node [
rdf:type sh:NodeShape ;
sh:property [
sh:path skos:inScheme ;
sh:hasValue atold:language ;
] ;
] .
```
Currently, this feature is NOT for capturing changes in the domain,
range and cardinality, and is only for the case of ADDED instances of
such resources, not their modifications.
The information won't show up for individual property changes on the
resources (added/updated/changed/moved labels and the whole shebang).
The queries in those cases will differ between modification types, and
there is the question of how to fit all of the information in an
already-crowded table. Work will continue on how best to approach this.
P.S: There are nested OPTIONALs as the graph may not exist, so
performance may be affected, though hopefully not by too much. If that
becomes a concern, we can turn these over onto a new template, where a
SHACL graph would be made mandatory.
Application of meaningfy-ws/diff-query-generator#34.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Support fetching domain, range and cardinality information from vocabularies containing a SHACL graph. The queries are different depending on whether it is an object property or a datatype property. Where the information isn't available, there will be empty cells in the report.
There is also support for value node constraints for certain patterns of expressing ranges for IRIs with
sh:hasValue, such as SKOS vocabularies, used for example in recent versions of the eProcurement ontology (ePO):sh:nodeKind sh:IRI ; sh:node [ rdf:type sh:NodeShape ; sh:property [ sh:path skos:inScheme ; sh:hasValue atold:language ; ] ; ] .Currently, this feature is NOT for capturing changes in the domain, range and cardinality, and is only for the case of ADDED instances of such resources, not their modifications.
The information won't show up for individual property changes on the resources (added/updated/changed/moved labels and the whole shebang). The queries in those cases will differ between modification types, and there is the question of how to fit all of the information in an already-crowded table. Work will continue on how best to approach this.
P.S: There are nested OPTIONALs as the graph may not exist, so performance may be affected, though hopefully not by too much. If that becomes a concern, we can turn these over onto a new template, where a SHACL graph would be made mandatory.