#169: Introduce classes sh:ShapesGraph and sh:DataGraph

[HolgerKnublauch]

Closes #169

• See this document rendered online here

[nicholascar]

Just slight wording changes to make the class definitions read as per their semantics - specialised forms of ontology. The real work is done by the definitions in the written spec of "data graph" and "shapes graph".

I've also edited the definition of "shapes graph" so that it's not conditional on it being passed into a validation process - "may be" not "is" - as we will potentially see shapes graphs defined that are not (only) used for validation, e.g. UI generation.

[ajnelson-nist]

A few remarks on trying to subclass owl:Ontology:

OWL 2 DL does not permit encoding x rdfs:subClassOf owl:Ontology .. I don't understand the full motivation from back then, but the precise statement fiatting "no" is in OWL 2 Syntax, Section 5.1:

IRIs from the reserved vocabulary other than owl:Thing and owl:Nothing MUST NOT be used to identify classes in an OWL 2 DL ontology.

owl:Ontology is in the reserved vocabulary - see Table 3 in Section 2.4.
(CORRECTION, found by @mgberg below - owl:Ontology is not in that table, but my understanding is it does have reservations that prevent it from being subclassed.)

So, from the OWL perspective, if SHACL Core's graph included the axiom sh:ShapesGraph rdfs:subClassOf owl:Ontology ., then SHACL Core's graph would bump any OWL ontology importing it into OWL Full. I haven't checked lately, but so far I don't think SHACL Core has issues that outright violate OWL 2 DL rules (an aside: rdfs:domain and rdfs:range can reference owl:Ontology), so this risks being the first statement that prevents SHACL Core from being imported into a big graph that tries to maintain OWL 2 DL conformance.

I think the above is unlikely to cause concern for those who use both OWL and SHACL together, since SHACL's definition graph is likely to be treated like OWL's definition graph. I forget where this is recorded, but I've seen in the OWL docs that OWL's definition graph can't be imported into an OWL ontology without bumping the ontology to OWL Full.

We could maintain the spirit of sh:DataGraph and sh:ShapesGraph being sibling classe of OWL Ontology by encoding in SHACL-SHACL rules like this, IRI(s) TBD:

shsh:OntologySpecializationShape
	a sh:NodeShape ;
	sh:class owl:Ontology .
	sh:targetClass sh:DataGraph , sh:ShapesGraph ;
	.

Then, the range of sh:shapesGraph and the like could read:

sh:entailment
	rdfs:domain owl:Ontology, sh:ShapesGraph ;
	.
sh:shapesGraph
	rdfs:range owl:Ontology, sh:ShapesGraph ;
	.
sh:suggestedShapesGraph
	rdfs:range owl:Ontology, sh:ShapesGraph ;
	.

[mgberg]

owl:Ontology is in the reserved vocabulary - see Table 3 in Section 2.4.

I don't see owl:Ontology in that table, am I missing it?

[ajnelson-nist]

owl:Ontology is in the reserved vocabulary - see Table 3 in Section 2.4.

I don't see owl:Ontology in that table, am I missing it?

Thank you for catching that. I had seen an OWL 2 validator flag each of these as outside OWL 2 DL:

owl:Ontology
        a owl:Class ;
        .

ex:O
        rdfs:subClassOf owl:Ontology ;
        .

ex:OP-1
        a owl:ObjectProperty ;   # AnnotationProperty is fine.
        rdfs:domain owl:Ontology ;
        rdfs:range owl:Ontology ;
        .

Unfortunately, that validator does not link to specific parts of the OWL specification describing why. (I think my institution's rules would frown on me naming the tool in this instance - apologies for those who wish to reproduce for themselves.) I had known them before, but cannot recall them at the moment, and I'm about to be in meetings for a good chunk of the day.

So, my references above are not correct, for which I apologize. I do believe the end effect is true, though, in that subclassing owl:Ontology would firmly make SHACL-Core incompatible for importing into OWL 2 DL. In mix-in cases, I don't know how commonly SHACL-Core is imported, rather than its vocabulary just used alongside class specifications in RDFS or OWL.

[HolgerKnublauch]

@ajnelson-nist I don't think shsh:OntologySpecializationShape implements what you would want. It basically says that any instance of sh:ShapesGraph MUST also be an instance of owl:Ontology. So it acts as a constraint check, while rdfs:subClassOf would act as an inference. Enforcing this constraint would either require all ShapesGraph instances to be double-typed with owl:Ontology, or the system ontology imported that adds the subClassOf triple.

In general, I am highly doubtful that many SHACL graphs fall under OWL DL anyway. I have lost track if OWL DL is even still relevant. My impression is that the majority of OWL implementations are just OWL RL, which ignores any triples on which an OWL DL engine would block.

[ajnelson-nist]

@ajnelson-nist I don't think shsh:OntologySpecializationShape implements what you would want. It basically says that any instance of sh:ShapesGraph MUST also be an instance of owl:Ontology. So it acts as a constraint check, while rdfs:subClassOf would act as an inference. Enforcing this constraint would either require all ShapesGraph instances to be double-typed with owl:Ontology, or the system ontology imported that adds the subClassOf triple.

That actually IS what I intended. I'd written my above remarks concerned with subclassing owl:Ontology leading to parsing OWL-specific problems. I'm no longer convinced my original reason holds, i.e., it might actually be fine from the OWL specification to subclass owl:Ontology and consider owl:Ontology a owl:Class. However, there is a likely problem with the OWL parsing algorithm affecting owl:imports, and this could be a pretty broad effect.

The OWL-RDF mapping document, Section 3.1.1, prescribes specifically how to interpret owl:imports. Specifically, there must be a pair of triples to trigger the "reach-out" behavior: x a owl:Ontology . must accompany x owl:imports y ..

Hence, this might be a problematic statement for users following this sequence:

1. Their application is built with a data graph as a store, today or earlier. The data graph houses an identifying IRI, and ties to an ontology "TBox" graph housing classes and properties.

# ExampleDataGraph-37.ttl
<http://example.org/ExampleDataGraph-37>
  a owl:Ontology ;
  owl:imports <http://example.org/ExampleOntologyGraph> .
  .

2. We merge PR 814 , defining the specialization class including these axioms:

sh:DataGraph
  rdfs:subClassOf owl:Ontology ;
  .

3. ExampleOrg goes through a classification exercise, and replaces some ABox headers with this:

# ExampleDataGraph-37.ttl
<http://example.org/ExampleDataGraph-37>
  a sh:DataGraph ;
  owl:imports <http://example.org/ExampleOntologyGraph> .
  .

4. Some applications processing ExampleDataGraph-37.ttl might now stop executing the owl:imports statement. From reading the OWL-RDF parsing algorithm, it looks like owl:imports would be skipped in the ontology header processing step, and just shifted to being a generic owl:AnnotationProperty with no effect. (This should raise no parsing errors because owl:imports is another one of those owl:-prefixed IRIs that isn't reserved, per the consumptive parsing prior to Table 18 in the parsing doc. Thanks again to @mgberg for inspiring me to check this more often.)

I should note, I don't know how common this behavior would be. But, by any strict implementation of the OWL-RDF parsing algorithm, this would be an unexpected failure from the user's perspective.

This is why I suggested that shape-form above. I agree that sh:DataGraph is a useful classification. However, I do not think it should subsume statements that an OWL parser might require before running any kind of entailment as pre-processing.

I do realize an implementation issue with the way I spelled the shape. It should do a direct interrogation for an rdf:type owl:Ontology triple, rather than doing a sh:class review, since sh:class would likely look to SHACL-SHACL's knowledge of SHACL-Core.

In general, I am highly doubtful that many SHACL graphs fall under OWL DL anyway. I have lost track if OWL DL is even still relevant. My impression is that the majority of OWL implementations are just OWL RL, which ignores any triples on which an OWL DL engine would block.

Oh, is ignoring the behavior you're seeing? My understanding was OWL RL being more restrictive than DL would mean engines would be suggested to halt more often; but, I haven't experienced a wide variety of RL implementations. (This is an aside, we don't need to dig into it here.)

[HolgerKnublauch]

@ajnelson-nist with apologies in advance but I am not an expert of the details of OWL DL parsing algorithms. Nor am I up to date on how many OWL RL tools will reject graphs that use features that go beyond OWL RL.

If this whole topic is causing such complications, I'd rather not touch it and maybe someone else can take ownership of this ticket.