Re: New Terminology Section

On Mon, May 9, 2016 at 10: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.


A clarification here, SHACL (as defined now) takes into account only
subclass relations that exist in the data graph


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


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org,
http://aligned-project.eu
Homepage: http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT