Re: New Terminology Section

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?

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