Add support for defining ranges/classes when generating a graph #291
Conversation
This file contains 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
There are two of them that are not added: * All the properties that have `skos:Concept`. Adding this class makes the range validation pass, but the shapes one fail, because we need to provide a `skos:prefLabel` value. This makes sense but the parser does not currently support it. It will probably have to be implemented as part of codelists support * All the properties that have `dcat:Dataset` range. Again, this makes the range tests pass but the shapes fail, because a `dct:title` and `dct:description` is expected of `dcat:Datasets`. I actually think this is a mistake on the validation, as it doesn't make sense to require those for referenced datasets (things like `serves_dataset` or `is_version_of`).
TODO: add a field to handle this or guess it from the CKAN license model
|
@seitenbau-govdata @EricSoroos and other Semantic experts, would be good to get your take on this |
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.
Starting off from some great work from @EricSoroos in #284, this PR modifies the base profile to support defining the range (
rdf:type) of properties._add_triple_from_dict()& co now accept an optional_classparameter which is the RDF class that will get applied to the object, if it is a URIRef. Classes can not be applied to Literals, otherwise you get invalid serializations.I added a SHACL test using the
dcat-ap_2.1.1_shacl_range.ttlshapes and we almost got to full validation but not quite. There were two classes that were not added to the profiles even if the range tests where failing:skos:Concept. Adding this class makes the range validation pass, but the shapes one fail, because we need to provide askos:prefLabelvalue. This makes sense but the parser does not currently support it. It will probably have to be implemented as part of wider codelists support (which @EricSoroos also started on DCAT HVD 2.2.0 #284)dcat:Datasetrange. Again, this makes the range tests pass but the shapes fail, because adct:titleanddct:descriptionis expected ofdcat:Dataset. I'm confused by this one, as it doesn't make sense to require those for referenced datasets (things likeserves_datasetoris_version_of) but maybe I'm missing something.Both seem like not important enough to block the whole support for ranges, so until we find a way around it the range test ignores them