Members of metaclasses should explicitly be classes

[ajnelson-nist]

This is a follow-on to PR 512, which, among other things, initiated a metaclass design pattern. I have no complaints about the pattern's design, but did come across an implementation detail that I think would be helpful to spell more explicitly.

The instances of metaclasses are currently subjects of rdfs:subClassOf, but are not themselves rdfs:Classes. There are a few benefits to being explicit that these nodes are rdfs:Classes:

• If they are classes, the OWL casting for Issue 246 can just look for instances of rdfs:Class.
• Seeing the extra rdf:type on a rdfs:Class emphasizes that these are intentionally members of meta-classes; and, likewise, there are meta-classes floating around somewhere.
• There is a reduced chance of confusion from seeing rdfs:subClassOf on something that is not explicitly an rdfs:Class.

I came across the now-missing rdfs:Class statements because a prior state of Issue 246's PR had already done the casting of sh:SelectExpression and sh:SPARQLExprExpression, but post PR 512, it looked like they'd dropped, and I became curious if they'd migrated to shnex.ttl. They didn't; they'd just lost the a rdfs:Class triple I'd been relying on in my CONSTRUCT query.

I'll file a PR momentarily to add a rdfs:Class to all the subjects of rdfs:subClassOf.

[HolgerKnublauch]

I have looked into this and your PR, but I don't think we should do this. The PR basically adds a new (redundant) rdf:type triple. This introduces problems:

• Tools such as forms need to figure out which view shape to use for instances of this: shall it use the more specific type or the superclass rdfs:Class?
• Algorithms that traverse those need to take into consideration that they have visited rdfs:Class before
• For consistency, any future and user-defined node expression function would need to also specify this extra triple
• Where to end this? If we start adding extra types for superclasses, the same argument could be applied everywhere, e.g. when someone instantiates owl:Class shall they also add rdf:type rdfs:Class?

In general I would like to keep the system vocabulary as lean as possible. If you find extra triples helpful for your use cases, I would suggest you place them into some other graph.

[ajnelson-nist]

@HolgerKnublauch : I'm finally coming back to this after a challenging September and then some AFK events. Apologies for the delayed reply.

I have looked into this and your PR, but I don't think we should do this. The PR basically adds a new (redundant) rdf:type triple. [...]

Looking at RDF Schema for rdfs:subClassOf (1.1, 1.2 current state), I now see that indeed there is an implication, in English definition and rdfs:domain and rdfs:range statements, that x rdfs:subClassOf y implies x a rdfs:Class . y a rdfs:Class .. It's not clear to me if the RDFS entailment patterns (1.1, 1.2) are supposed to "bootstrap" the entailment process with rdfs:subClassOf rdfs:domain rdfs:Class ; rdfs:range rdfs:Class .. (And, I think OWL's model is out of scope here.). Point being, this is one of those corner cases of RDF requiring a lookup to see if skipping x a rdfs:Class is a modeling error or a permissible implicit pattern.

So, I disagree that the triple is redundant. x rdfs:subClassOf y with no triple x a rdfs:Class (or x a owl:Class, or x a sh:ShapeClass) is, to me, an incomplete specification, and leaves a dangling question to a user, or their graph application, "Wait, should this model be able to instantiate an x?". As spelled prior to #576 , shnex:NamedParameterExpression is instantiable, but its not explicitly encoded with rdf:type rdfs:Class that its specialization shnex:CountExpression is.

Not including shnex:CountExpression a rdfs:Class . for NamedParameterExpressionFunctions (etc.) imposes a requirement on a consumer of shnex.ttl: That if it wants to know all the rdfs:Classes, it must search for x a rdfs:Class and y rdfs:subClassOf z.

[...] This introduces problems:

• Tools such as forms need to figure out which view shape to use for instances of this: shall it use the more specific type or the superclass rdfs:Class?

I believe this question is raised already by the presence of rdfs:subClassOf. If a tool finds a triple x rdfs:subClassOf y, should it or should it not automatically assign x and y to be classes? Does it help for SHACL to verbally remind consumers that with rdfs:domain/range entailment that there would be more rdfs:Classes than are explicitly encoded?

With an example erring the other way: I could have written the figure-generator for Discussion 380 using only x rdfs:subClassOf y triples. IIRC, I happened to build the set of z a rdfs:Class for coverage-checking, but I didn't think I needed to. If I just went with rdfs:subClassOf triples, is it more appropriate to include or exclude those IRIs that aren't explicitly typed as rdfs:Class?

Relatedly, I think it is a decision best considered consciously by a tool, how to handle a metaclass design. Metaclass design is a significant leap in modeling complexity and probably user interface issues. I feel an application should be informed explicitly if there are classes whose members are non-classes (e.g., phoenicopterus ruber, a class of birds) and classes whose members are classes (e.g., specie), and design for (or consciously skip) either level of abstraction.

• Algorithms that traverse those need to take into consideration that they have visited rdfs:Class before

Fair. My personal preference is to do a pass for classes anyway, but to each modeler their own.

• For consistency, any future and user-defined node expression function would need to also specify this extra triple

Yes.

• Where to end this? If we start adding extra types for superclasses, the same argument could be applied everywhere, e.g. when someone instantiates owl:Class shall they also add rdf:type rdfs:Class?

I admit I don't see the concern on this point - extra type for superclass? Do you mean defining a (probably sole) higher-order class in SHACL, whose members are meta-classes? I'm perfectly fine NOT doing this, unless a need arises. I've only seen one ontology in the OWL sphere prepare modeling for this, and I can't currently imagine a great need in SHACL to go this far.

I also don't see the projection of rdfs:Class on every class-modeling syntax. I thought we'd already discussed this point to conclusion on Issue #212 . I'm just pushing for it on members of meta-classes.

In general I would like to keep the system vocabulary as lean as possible. If you find extra triples helpful for your use cases, I would suggest you place them into some other graph.

I think being lean and leaving users to miss things is less ideal than being explicit that there was a challenging model (per your notes in PR #512) implemented.

Absent objection, I will update PR #576 , though not Tuesday.

[TallTed]

@ajnelson-nist -- In the last sentence of the third paragraph of your latest, there's an apparent typo, which makes understanding an already complex post more difficult. I believe that this --

see if skipping `x rdf:type a rdfs:Class` is a modeling error

-- should probably be this --

see if skipping `x rdf:type rdfs:Class` is a modeling error

-- or maybe this --

see if skipping `x a rdfs:Class` is a modeling error

-- depending on which preceding and/or following statement you want to echo.

[ajnelson-nist]

Whoops! Good eye, @TallTed . I've revised the comment in-place.

[TallTed]

[@ajnelson-nist] I think being lean and leaving users to miss things is less ideal than being explicit that there was a challenging model (per your notes in PR #512) implemented.

This is a judgement call that must be made every time a model is built or instantiated.

• What do you say explicitly?
• What do you leave for later inference?
• How can you be sure that the things you infer from what's been stated will be the same things that downstream inference engines (or people) will infer, and thus what else do you say explicitly?
• How can you be sure that every explicit statement is really necessary and won't consume more storage space or active memory or other resource(s) than will be available every time the model is put to use?

Here on the bleeding edge, I find that stating only what needs to be stated and no more is an ongoing challenge. I don't think we'll solve it here, but hopefully we'll get closer.

[HolgerKnublauch]

disagree that the triple is redundant. x rdfs:subClassOf y with no triple x a rdfs:Class (or x a owl:Class, or x a sh:ShapeClass) is, to me, an incomplete specification

Compare with other well-known ontologies such as SKOS. It explicitly states that skos:Concept is an instance of owl:Class. It doesn't state that it's an instance of rdfs:Class though, because that is implied (e.g. because any object of an rdf:type triple is inferred to be rdfs:Class because rdf:type rdfs:range rdfs:Class.

https://www.w3.org/TR/skos-reference/#concepts

https://www.w3.org/TR/rdf12-schema/#ch_type

I don't think SKOS is considered an incomplete specification, and this highlights my question of where to stop.

[ajnelson-nist]

disagree that the triple is redundant. x rdfs:subClassOf y with no triple x a rdfs:Class (or x a owl:Class, or x a sh:ShapeClass) is, to me, an incomplete specification

Compare with other well-known ontologies such as SKOS. It explicitly states that skos:Concept is an instance of owl:Class. It doesn't state that it's an instance of rdfs:Class though, because that is implied (e.g. because any object of an rdf:type triple is inferred to be rdfs:Class because rdf:type rdfs:range rdfs:Class.

https://www.w3.org/TR/skos-reference/#concepts

https://www.w3.org/TR/rdf12-schema/#ch_type

I don't think SKOS is considered an incomplete specification, and this highlights my question of where to stop.

Sorry, I'm not following your SKOS example. I followed your link, see "skos:Concept is an instance of owl:Class ." in Section 3.3, and see an example in 3.5 that is a separate example of a skos:Concept as a metaclass: <MyConcept> rdf:type skos:Concept , owl:Class ., noting that pattern is also consistent with SKOS because SKOS "does not make any additional statement about the formal relationship between the class of SKOS concepts and the class of OWL classes".

If a SKOS concept is also an owl:Class, then it's up to the application to decide whether it's worth calling out as a class, or lumping it in with the individuals, or both. Individuals that are instantiable are, IMO, worth recognition as such.

On your note of owl:Class entailing rdfs:Class: Yes, that is fine for those who follow all the RDFS semantics of the OWL namespace graph. I think if an application was trying to be completist with finding all instances of meta-classes, then if they want to treat the OWL definition graph as part of their domain of interest, it's completely fair game for them to include owl:Class in their set of meta-classes. Under RDFS semantics, it is. But, loading OWL's namespace graph into the domain graph is probably not going to be a common occurrence.

By the way, I found that statement akin to "Don't load the OWL namespace into an OWL DL graph:" It's in the OWL namespace graph, right at the top.

[...] This ontology SHOULD NOT be imported
into OWL ontologies. Importing this file into an OWL 2 DL ontology
will cause it to become an OWL 2 Full ontology and may have other,
unexpected, consequences.

Meanwhile, I've caught #576 up and found the metaclass pattern was quite broad across the shnex: namespaces. I personally find that compelling to call out, because it was pretty obscured in shnex-sparql that so many of the concepts were meta-classes.