W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: New Terminology Section

From: Holger Knublauch <holger@topquadrant.com>
Date: Tue, 10 May 2016 13:18:34 +1000
To: RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Message-ID: <ee71aa51-8c3c-0436-75ca-cfe299eafa7b@topquadrant.com>
On 10/05/2016 12:30, Tom Johnson wrote:
>
>
> On Mon, May 9, 2016 at 5:29 PM, Holger Knublauch 
> <holger@topquadrant.com <mailto:holger@topquadrant.com>> wrote:
>
>
>
>     On 10/05/2016 10:11, Tom Johnson wrote:
>>     Irene, you say:
>>
>>     >"Doing more" doesn't create a problem, but, on the other hand, it
>>     is not required.
>>
>>     I'm really uncertain about this. Couldn't inferring further class
>>     relations (e.g., by using the entailment mechanism included in
>>     the spec) cause different results for basically every operation
>>     in SHACL?
>
>     Can you think of a specific example? sh:entailment would
>     potentially produce additional triples. But this is the user's
>     choice, and then the user may expect to see additional validation
>     results...
>
>
> We seem to be in agreement that inferring additional triples will 
> change results. Examples seem obvious; adding a `subClassOf` statement 
> whose subject is any class referenced in a shape will do the trick, 
> but that's far from the only example.
>
> This seems like a problem to me because I don't see that it's clear 
> where triples like `subClassOf` must appear (data graph? shapes graph? 
> any graph?) for a resource to count as a shape, or to match various 
> constraint components.

To have an effect on sh:scopeClass and sh:class, the subClassOf triples 
must be in the data graph.

> Note that adding a `subClassOf` triple to a shapes graph to effect 
> validation could be considered a feature; I'm unsure whether that 
> feature is supported.

Currently the spec only looks at the data graph.

>
> Additionally, `sh:entailment` seems generally under/un-defined. Can 
> inference effect data graphs only? or also shapes graphs? Which 
> triples can be considered by a reasoner and how are inferred triples 
> used by the SHACL semantics?

I have just clarified this to the sh:entailment section:

https://github.com/w3c/data-shapes/commit/71a9eeaff0317de0cdca6b36500412dabc922f78

I am unsure how many people will actually use sh:entailment, so any 
feedback/requirement may help us add missing details. It is very brief 
right now, indeed.

Holger

>
> Some of my other concerns about the specifics of `class` and 
> `instance` definitions seem to be in the process of being fixed up; 
> from a quick reading of the latest editor's draft, this is looking 
> promising.
>
> - Tom
>
>     Thanks, i
>     Holger
>
>
>
>>
>>     In lieu of a repeat of previous conversations, I'll just say: For
>>     me, as an implementer in waiting, this is a huge problem. On last
>>     reading, very little seemed unambiguously defined.
>>
>>     - Tom
>>
>>     On Mon, May 9, 2016 at 12:14 PM, Irene Polikoff
>>     <irene@topquadrant.com <mailto:irene@topquadrant.com>> wrote:
>>
>>         Karen,
>>
>>         As I understand it, RDFS inferencing is one way to address
>>         this. However,
>>         RDFS inferencing would do more than what is specified here.
>>         "Doing more²
>>         doesn¹t create a problem, but, on the other hand, it is not
>>         required.
>>
>>         Another way to address this is to run a query as follows:
>>
>>         SELECT ?resource
>>         WHERE {
>>
>>         ?class rdfs:subClassOf* example:Class1 .
>>         ?resource a ?class .
>>
>>         }
>>
>>         Running this query would not change any graphs. As an aside, RDFS
>>         inferencing is also often done without modifying any graphs.
>>         Inferences
>>         are calculated on the fly when users/systems query data
>>         without any
>>         materialization of inferred triples. At least, this is how
>>         triple stores
>>         that support RDFS inferencing typically work.
>>
>>         Does your concern have to do with where the rdfs:subClassOf
>>         triples come
>>         from - would they exist in the data graph, would they exist
>>         in the shapes
>>         graph? They could be in either. If no subclass triples are
>>         there, then the
>>         first triple match simply binds ?class to example:Class1 and
>>         the query
>>         result is the same as if we were only looking for nodes that
>>         are connected
>>         to example:Class1 via rdf:type link.
>>
>>         It doesn¹t seem to be a role of SHACL to mandate where these
>>         triples
>>         should be located. If they are available in either of the
>>         graphs, a SHACL
>>         engine should take them into account. If they are not
>>         available, than it
>>         doesn¹t take them into account.
>>
>>         In our experience, users typically put the subclass triples
>>         into the
>>         shapes graph. At the same time, they need flexibility to do
>>         whatever fits
>>         their architecture and processes.
>>
>>
>>         Irene Polikoff
>>
>>
>>         On 5/9/16, 1:47 PM, "Karen Coyle" <kcoyle@kcoyle.net
>>         <mailto:kcoyle@kcoyle.net>> wrote:
>>
>>         >Type
>>         >The types of a node are its values of rdf:type as well as the
>>         >superclasses of these values.
>>         >
>>         >This conflates two different relationships: the relationship
>>         of a
>>         >subject to a class (as defined in RDF/RDFS), defining the
>>         subject as an
>>         >instance of the class; and the sub-/super-class
>>         relationships between
>>         >classes. I dont' see how this can be achieved without
>>         inferencing.
>>         >
>>         >If we assume some pre-processing of the data graph to
>>         include the
>>         >superclasses, then type is precisely as it is defined in RDF
>>         - there are
>>         >just more type statements in the graph.
>>         >
>>         >As stated, this is quite an expansion of the meaning of type. In
>>         >addition, it appears to require modifications to the data
>>         graph to
>>         >include the super classes of each class (presumably up to
>>         and including
>>         >rdfs:Resource).
>>         >
>>         >I think it would be best if SHACL defined the shape and data
>>         graphs as
>>         >immutable, thus expecting that all operations read but do
>>         not modify the
>>         >graphs. I thought we had come to that conclusion.
>>         >
>>         >kc
>>
>>
>>
>>
>>
>>
>>     -- 
>>     -Tom Johnson
>
>
>
>
> -- 
> -Tom Johnson
Received on Tuesday, 10 May 2016 03:25:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC