owl imports of other shape graphs

[rdflib]

owl imports of other shape graphs

[ashleysommer]

@fils
I couldn't wait until after 1.0. 😛 I spent some time today and I've implemented basic owl:imports support.
I tested your example and it seems to work now, with the new version v0.9.10.

Some caveats (as much for me to document it somewhere, as it is potentially informational for you):

• It only works 3 levels deep (plus the base level), for example, if a.ttl imports b.ttl, and b.ttl imports c.ttl, and c.ttl imports d.ttl, that is the max it can go, anything that d.ttl imports will be ignored.
• It only works on the SHACL Shapes graph file, and the extra ontology graph file. You cannot use owl:imports in the Data graph (well you can, but it doesn't do anything).
• It only works if the owl:imports statement is assigned on the base uri of the file.

#baseURI: http://example.com/myontology

@prefix owl: <http://www.w3.org/2002/07/owl#> .

<http://example.com/myontology> owl:imports <http://example.com/nextfile> .

• OR on the URI you have defined as a blank prefix:

@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix : <http://example.com/myontology#> .

: owl:imports <http://example.com/nextfile> .

• OR if you have explicitly assigned the subject as an owl:Ontology :

@prefix owl: <http://www.w3.org/2002/07/owl#> .

<http://example.com/myontology> rdf:type owl:Ontology ;
            owl:imports <http://example.com/nextfile> .

[fils]

@ashleysommer Oh sweet! I'm in transit today but I'll try this at the hotel. I'm actually heading to a semantics conf in Durham, so I'm hoping to get some time to chat SHACL with people..

thanks!

[ashleysommer]

@fils
Thanks for using pyShacl!

Firstly, there is nothing technically wrong with what you are doing. The owl:imports axiom allows you to declare that the base graph should be expanded with the contents of an external graph. And using a GitHub raw file URL is a valid location to point it at.

However there a couple of reasons it isn't working for you in this case.

owl:imports is a statement from OWL2 ontology and is an OWL construct. This means it doesn't do anything on its own by simply existing in your Shapes File. PyShacl uses RDFlib under the hood for loading and parsing RDF files to graphs. RDFlib doesn't do anything special when it sees an owl:imports, it doesn't follow it and doesn't download or include anything else. If you were to run this graph through an OWL2-compliant graph-expander then it may download and include the target file into the graph, or not, depending on the graph-expander's import policy.

PyShacl has an optional argument that instructs the validator to run an OWL2 reasoning/inferencing graph-expander on the Data-Graph prior to validating, but that doesn't apply to the Shapes Graph. And even if it did, the OWL2 library we use (OWL-RL) has a no-imports policy so it wouldn't work anyway.

So why do they use owl:imports in the examples in that book?
I'm guessing other SHACL implementations have a special-case rule that looks for owl:imports in a loaded Shapes File graph, and downloads and includes them. Or that feature is present in the backing RDF loading/parsing library they are based on.

We have certainly discussed the pros and cons of including such a feature in pyShacl. And your creation of this issue will reignite that conversation. There is a chance it will be added in the future, but it will be post-1.0.

[fils]

@ashleysommer

Thanks for taking the time for that very detailed and very helpful post! Much appreciated!

I'll keep watching to see any further development and for now will just return to the concept of keeping my shape graphs as self contained files. Or I can just break them up and do run multiple runs of pyshacl for the various sets of shapes to test, like required, recommended, etc. etc.

To give you some context to all this. Several of us are working on schema.org based metadata for various data facilities and some government agencies. One issue though is that some of the tooling is a bit lacking. (I'm looking at you, Google Structured Data Testing Tool) So a thought has been to define the shapes we are after and essentially do a sort of "test driven development" pattern from software land. This also lets us ensure that extensions to schema.org, which we need, can be checked since SDTT just throughs them as errors.

Thanks!

I'm curious to give this a try and this is the start of all that.