[rdf4j-dev] SHACL next features

[Håvard Ottestad <hmottestad@xxxxxxxxx>]

Hi,

The SHACL sail has shaped on nicely over the last few months. There are a number of hurdles before we are (or ever will be) compliant with the W3C specs.

Two big features that we don’t support yet:
 - Restrictions on node shapes
 - Complex paths

The most common and useful restrictions on SHACL are property restrictions. Basically equivalent to “foaf:Person foaf:age max 1”, foaf:Person can only have 1 age. SHACL also supports restrictions directly on the node shape. I don’t have very good examples for when to use them (and there aren’t really very many in the SHACL spec either). The only half decent one I can think of is “foaf:Person only IRI”, all foaf:Person must be IRI (and not blank node), this is different from the more common usecase of “foaf:Person only foaf:knows IRI”, eg. you can only know things that are IRI.

Complex paths can be explained as “SHACL spec supports pretty much any and all kinds of paths and path combinations you can think of”. Things like: “foaf:Person foaf:knows*/rdf:type/rdfs:subClassOf^/rdfs:label|dc:prefLabel max 1”. This is a bit overkill if you ask me, but that’s the spec :( Supporting this is going to be challenging, and use of it will impact the performance big time! 


Other features we should have:
 - Modify existing shapes

It’s not going to be the norm, but every once in a while someone needs to modify the SHACL shapes (restrictions) currently in use. We have two roadblocks at the moment when it comes to supporting that. First is that we run some SPARQL enrichment queries on the shapes, since the spec is very flexible there are multiple ways to support the same thing and normalising all the shapes before we parse them into java objects is easier than writing lot’s of java code. 

The second thing holding us back from allowing users to modify existing shapes is how we handle validation. Validation currently works by analysing changes, but when the user changes the currently loaded shapes I think they expect the entire database to be revalidated. There is some rudimentary support for this implemented due to changes in how sh:or works, but I think it’s far from perfect. Performance isn’t the biggest issue either, since it’s a task the user hopefully won’t do too often. Memory pressure will be an issue, we need to be able to revalidate the database without needing to load large chunks of it into memory!

So fun times ahead :)

Cheers,
Håvard