SHACL shapes to enforce and document model

[rjyounes]

I've long argued against including SHACL shapes with gist, since an upper ontology itself is not populated with data and SHACL by nature is implementation-specific. However, it now occurs to me that there is some small group of cases where SHACL could be used to explain and enforce correct implementation of the model. Ordered collections and ordered members provide one example:

• All members of OrderedCollections are OrderedMembers.
• OrderedMembers. are only members of OrderedCollections.
• An OrderedMember is a member of exactly one OrderedCollection.
• An OrderedMember has exactly one providesOrderFor triple.
• An OrderedMember is either the subject of gist:sequence or gist:precedesDirectly, or is the object of gist:precedesDirectly.

Granted that these are all in the ontology axioms; however, SHACL can be useful for implementers to make sure they have correctly understood and implemented the model. Note that I don't think every axiom is a candidate for SHACL. E.g., an ordered collection is either empty or has a first member. I don't expect all implementations to materialize hasFirstMember triples, and therefore wouldn't include it in gist SHACL.

This has occurred to me because I am now writing exactly this SHACL for a client project; it would have been useful were it provided with gist.

[dylan-sa]

SHACL can be useful for implementers to make sure they have correctly understood and implemented the model

I could see it being useful for enforcing closed-world constraints that can't be enforced with OWL. If all OrderedMembers should have exactly one providesOrderFor triple, the "max 1" part could in principle be enforced by OWL (given that providesOrderFor is functional and the providesOrderFor objects are distinct), whereas the "min 1" component would need to be enforced by SHACL.

Some of the axioms above should (in theory, at least) catch bad data w/ an OWL reasoner on. But in cases where we want to enforce the existence of something to ensure proper implementation, SHACL could be helpful.

[rjyounes]

This is a good point, but many or most implementations do not run reasoners for performance reasons. There are also the cases I mention above, where we deliberately rely on the OWA to express semantics that may not be implemented, as in the hasFirstMember example.

Providing this SHACL would also be a service to implementers so they don't have to do it themselves, as I mention above.

Anyway, it's worth thinking about the pros and cons of offering some SHACL.

[uscholdm]

If we start down this road, we should have clear criteria for when we do or do not include SHACL.

[uscholdm]

Some of the axioms above should (in theory, at least) catch bad data w/ an OWL reasoner on.

In practice, all OWL can do is discover the error, pointing to the fact that there is bad data. It is not so great at telling you where the bad data is. Also, in practice OWL reasoning support is minimal in triple stores.