Conversation
- adding order, name, description - adding example - docs
balhoff
left a comment
There was a problem hiding this comment.
I see that the property constraints are propagated down to subclasses. The NamedThing shape has targetClass NamedThing. Some of the constraints there (e.g. name) are also stated for its subclass Person. I think that any instances of Person would also be "SHACL instances" of NamedThing via the built-in RDFS inference. Then would they automatically have the NamedThing constraints without duplicating them? Not sure how these interact.
|
Yes, we should eliminate the redundancy. It's possible for subclasses to refine ranges other other constraints but where there is no override we should avoid redundancy can you also comment on the wisdom of "punning" class shape names and class_uris? |
One thing to keep in mind is that without the redundancy, you need to provide both the data and the schema ontology (in addition to the SHACL file) to the validator. Probably a good idea though, to make sure
I think it's fine; they have specific support for this: https://www.w3.org/TR/shacl/#implicit-targetClass You shouldn't need to also state |
| @@ -0,0 +1,324 @@ | |||
| @prefix ns1: <http://www.w3.org/ns/shacl#> . | |||
There was a problem hiding this comment.
Is there a way to change this to @prefix sh: <http://www.w3.org/ns/shacl#> ., just to follow convention?
…rage Exclude vendored linkml-model from coverage reporting
Note: will be hard to do complete tests until we switch to rdflib6, see #291 (this is because pyshacl depends on rdflib6)