Re: New Terminology Section

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...

Thanks,
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