Re: Accidental or Purposeful Inconsistencies?

[santino petrocelli]

Hello,

In evaluating Brick, I've seen what could be intentional punning, or unwelcome inconsistency in the latest, stable version (at least). Specifically, there are lots of instances of both owl:Class and sh:NodeShape. I won't enumerate them all, but here are some examples:

1. Brick:Loop

2. Brick:TimeseriesReference

3. Brick:System

4. Brick:AggregationShape

Admittedly, I am unfamiliar with punning of this variety -- namely, minting something as a shape and a class. So, I'm hoping if you can tell me whether this is intentional, and, if so, what it accomplishes that no logically consistent system can do (or can do well).

Thanks,

Santino

[Gabe Fierro]

Hi Santino:

It is indeed intentional! This is a pattern I borrowed from another ontologist; it essentially co-locates the constraints with the classes they pertain to. We found in practice that this made the Turtle file easier to read and debug because it makes it clearer which classes are subject to which constraints. I haven't found any system that complains about this arrangement. Can you be more specific about why this is an issue?

Best,

Gabe

[santino petrocelli]

Hi Gabe,

Thanks for a quick and informative reply. For some reason, I wasn't notified of it by mail. Oh, well. 

I see the value in an easier-to-read-and-debug Turtle file, and I understand how this is achieved by the relevant pattern. I was surprised -- which is consistent with my being wrong, of course -- to hear that systems don't complain about the arrangement, though. So, I looked into it a bit further. Here's a pattern that should be flagged as a violation by any system that's performing inference in any logic weaker than OWL Full:

                          brick:Loop a owl:Class, 

                                              sh:NodeShape .

                         sh:NodeShape a owl:Class.

Here's the pattern we actually see, which shouldn't, by itself, be an issue with any current system:

                        brick:Loop a owl:Class, 

                                            sh:NodeShape .

                        sh:NodeShape a rdfs:Class.

If sh:NodeShape were an owl:Class, then brick:Loop would be an owl:NamedIndividual -- via its instantiation of sh:NodeShape -- and an owl:Class, by direct assertion. But, sh:NodeShape isn't an owl:Class, it's an rdfs:Class. So, brick:Loop is a first-order class (or higher-order, depending on the OWL flavor) -- via its instantiation of owl:Class -- which entails that sh:NodeShape is either second-order (depending on OWL flavor) or variable-order -- which isn't in an issue in current systems, because it's an rdfs:Class rather than an owl one. 

Still, it seems like capitalizing on an unfortunate state of affairs to imply that sh:NodeShape is anything but first-order, a class whose instances are uninstantiable shapes. Presumably, an instance of sh:NodeShape necessarily doesn't have instances, itself. Even granting that it could have instances, I have questions about the aptness of the pattern in the case of the Brick ontology. According to the SHACL ontology:

                       sh:Shape rdfs:comment "A shape is a collection of constraints that may be targeted for certain nodes."@en 

Is brick:Loop a collection of constraints that may be targeted for certain nodes? The definition suggests otherwise, but maybe I've got a wrong view of things. 

I very much look forward to your reply! 

Santino 

[Steve Ray]

Santino,

I believe I might be the source of Gabe's pattern, but declaring something as an instance of two classes isn't really punning.

The pattern of declaring something as an instance of both sh:NodeShape and rdfs:Class is documented here and here.

I agree that using owl:Class instead of rdfs:Class might cause difficulties - personally I'm trying to live in just the SHACL world these days.

On a standard that Gabe and I are collaborating on, we use the following pattern, where our s223:Class is just a sibling of owl:Class. Both owl:Class and s223:Class are defined as rdf:type rdfs:Class AND rdfs:subClassOf rdfs:Class. 

Steve

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/52f09b0e-95c5-42ac-bf12-640a6ba816dfn%40googlegroups.com.

[santino petrocelli]

Hi Steve,

Thanks for your reply. I didn't mean to suggest that merely making something an instance of multiple classes constitutes punning. It's what I deemed to be a consequence of something's instantiating the particular classes of sh:NodeShape and owl:Class that is inconsistent. But, as I say above, given that sh:NodeShape is an rdfs:Class, it's unclear (to me, currently) whether there is inconsistency. 

Thank you for sharing the documentation! I failed to find that on my own, but it's exactly what's needed. I'll dig through it, and either reply here or attend one of the working group sessions. 

Re: your s223:Class, it exemplifies that an rdfs:Class can he higher-order, but it doesn't clear up some potential semantic issues raised by making an owl:Class an instance of sh:NodeShape. To be continued after some more research :)

Thanks again,

Santino

[santino petrocelli]

Thanks again, both, for your thoughtful replies. I've read the linked docs and, while I still think someone could reasonably be skeptical of the pattern, I see that there is clear precedent (at least for rdfs:Classes), and understand how SHACL processors treat it. 

Given that

       1) There's room for reasonable skepticism,

       2) It isn't clear whether using specifically owl:Classes in the pattern has precedent,

       3) The desiderata that are satisified by the pattern are to make ontology files easier to read and debug,

I think I might've opted for linking a blank node to the class, e.g.

       brick:Loop ^sh:targetClass [ a sh:NodeShape ; [ ... ]].

For now, I can't see any disadvantages of this. But, as a rule, I'll think of some as soon as I hit 'submit'.

Santino

[Steve Ray]

Santino,

Interesting alternative that you suggest! Maybe it's just me, but the use of an inverse relation from a blank node seems less natural than the good ol' use of "inheritance" to endow a class with additional behavior. However, it would definitely work.

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/8303f189-4238-4933-a25e-24f9eb44e6c7n%40googlegroups.com.

[santino petrocelli]

Steve,

I agree that inheritance is more natural than an inverse relation from a blank node, of course. (I lol'ed at your putting things this way, by the way.) The suggestion of using a blank node is just to enable syntactic locating of SHACL constraints alongside class definition. Without that desideratum, I'd've suggested a reified instance of sh:NodeShape that's got its definition some place else.

Re: using inheritance to "endow a class with additional behavior", this is where I -- perhaps idiosyncratically -- get off the boat. My sense is we should use inheritance to endow classes with additional meaning, rather than behavior. Let behavior be decided and carried out by consumers of the ontology, on the basis of the meaning in it. To my mind, making a class an instance of sh:NodeShape, despite the happily clearly defined behavior of a SHACL processor, is making some sort of meaning-based mistake. That said, if no current system complains about it, why should I?!

Santino

[Steve Ray]

Definitely an equally valid way of representing things - on that we are in complete agreement.

I see your point about meaning vs. behavior, but we could (and I won't) embark on a philosophical discussion about what is "meaning" in an ontology vs. "behavior". Is a cardinality constraint "meaning"? I agree that since an ontology is not executable in the sense of procedural code, I should not have used the word "behavior". The two words overlap in my mind for an ontology.

(I suppose I did embark a bit on that philosophical discussion!)

Steve

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/652c8ada-8318-4b34-8e1b-cd13cc392184n%40googlegroups.com.

[santino petrocelli]

I welcome philosophical discussions, for what it's worth! But, I register that you'd rather not have one on this forum, so I won't answer your rhetorical question about cardinality constraints :)

In any case, I think your inclination to see meaning and behavior as overlapping in the context of an ontology is bound up with your inclination to make classes shapes, and my inclination to separate them is bound up with my inclination not to. So be it. If systems aren't complaining about it, I don't want to make mountains out of molehills, or enemies out of potential collaborators.

Thanks again for your engagement!

Santino

[Gabe Fierro]

Thanks for digging in, both of you!

 

What I’m getting from this is that it is perhaps cleaner (or at least doesn’t force us to determine if owl:Class is higher order) for Brick to use rdfs:Class instead of owl:Class. I know for a fact that owl:Class is baked into many existing Brick queries and applications, so it may be some time before we can fix this issue. I think the earliest would be Brick 1.4.

 

The SHACL definitions of subclass, class, etc are detached from and do not leverage any of the RDFS or OWL flavors of semantics in their definition: https://www.w3.org/TR/shacl/#dfn-shape . In particular check out the definition of a SHACL subclass:

A node Sub in an RDF graph is a SHACL subclass of another node Super in the graph if there is a sequence of triples in the graph each with predicate rdfs:subClassOf such that the subject of the first triple is Sub, the object of the last triple is Super, and the object of each triple except the last is the subject of the next.

 

Given the current state of the document, the SHACL specification seems perfectly happy to exist alongside existing semantic frameworks

 

Best,

Gabe

 

Steve

 

.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/6348b8e9-bbda-429e-b88d-60c55b5da53en%40googlegroups.com.

[santino petrocelli]

Hi Gabe,

They don't directly reference rdfs or owl, but they do define classes in terms of SHACL types, which are defined as values of rdf:type, the range of which is rdfs:Class. 

Although, I admit I'm not sure why you're making these points about SHACL's independence. Is it as part of an investigation into how to avoid using owl:Class?

Santino

[Gabe Fierro]

Apologies, didn’t mean to confuse the issue further! I was simply noting that there doesn’t seem to be any explicit acknowledgement of any of these issues in the SHACL specification

[Joel Bender]

> ...but they do define classes in terms of SHACL types...

No, they define rules for collections of triples, the only statement
that defines a class is "ex:Thing a rdfs:Class". The sh:targetClass is
a shortcut for saying "if { ?x a ex:Thing } exists in the graph then ?x
is a target node of this set of rules." The sh:targetSubjectsOf and
sh:targetObjectsOf define additional ways of describing what nodes are
subjected to the rules.

You can say that there is some subset of the universe of graphs that
conform to some specific collection of shapes and call that a "class"
but that's not very useful.

> brick:Loop ^sh:targetClass [ a sh:NodeShape; [ ... ]] .

This isn't valid Turtle.


Joel

[Gabe Fierro]

Well, they do say “:x rdf:type sh:NodeShape”, which implies that sh:NodeShape is an rdfs:Class

 

From: brick...@googlegroups.com <brick...@googlegroups.com> on behalf of Joel Bender <jo...@carrickbender.com>
Date: Wednesday, August 31, 2022 at 2:03 PM
To: brick...@googlegroups.com <brick...@googlegroups.com>
Subject: Re: [Brick] Re: Accidental or Purposeful Inconsistencies?

--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brickschema...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/02550e3a-ce42-d508-dfd5-d13e4707550f%40carrickbender.com.

[Joel Bender]

> Well, they do say “:x rdf:type sh:NodeShape”, which implies that
> sh:NodeShape is an rdfs:Class

Sure, and that's a nice organizational way of distinguishing between
node shapes and property shapes, but doesn't say anything about :x being
a class, or that targets that satisfy the rules of the node shape are
therefore members of some class.

You might think that if "?x sh:targetClass ?y" appears in a graph then
"?y rdf:type rdfs:Class" should also appear or can be inferred, but
sh:targetClass isn't defined in terms of RDFS with a domain and range.


Joel

[santino petrocelli]

See here for definitions of "SHACL Class" and "SHACL Type":

       

       SHACL Class: Nodes in an RDF graph that are subclasses, superclasses, or types of nodes in the graph are referred to as SHACL class.

       SHACL Type: The SHACL types of an RDF term in an RDF graph is the set of its values for rdf:type in the graph as well as the SHACL                                                      superclasses of these values in the graph.

It's this notion of "SHACL Type" that entails that this notion of "SHACL Class" implicates rdfs:Class, contra what I took to be Gabe's point. 

Re: my invalid Turtle, of course you are right. It uses "[ ... ]", which I don't suppose is valid Turtle. It's just a convention in natural language for expressing the same as "etc." or "and so on" would. But, maybe your issue is with the use of the carat. If so, substitute it by an elsewhere defined an inverse property of sh:targetClass.  

[santino petrocelli]

See, among other things, the turtle defining sh:targetClass:

sh:targetClass a rdf:Property ;
                           rdfs:label "target class"@en ;
                           rdfs:comment "Links a shape to a class, indicating that all instances of the class must conform to the shape."@en ;
                           rdfs:domain sh:Shape ;
                           rdfs:range rdfs:Class ;
                           rdfs:isDefinedBy sh: .

[santino petrocelli]

FYI Gabe, I found an old doc comparing SHACL and OWL that takes for granted that an owl:Class can be a sh:NodeShape. Perhaps there's no need for refactoring Brick along these lines, after all. 

I also note that TopQuadrant's EDG docs don't say anything about inconsistency where one should expect they would, if there were such inconsistency: 

        Classes vs. Node Shapes

        When you create a new class in TopBraid EDG, it will always be also typed as a Node Shape. This is because you typically create classes in EDG          in order to describe instance of the classes – also known as class members. Instance data needs shape definitions and Node Shapes provide            such definitions.