Re: New Terminology Section

On 5/9/16 12:14 PM, Irene Polikoff 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.

That assumes a SPARQL query - I believe that is limited to the extension 
mechanism.

  As an aside, RDFS
> inferencing is also often done without modifying any graphs.

We have already decided that SHACL will not do any inferencing.


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?

The discussion is about sub/super-class relationships in the data graph. 
Section 4.2 says:

"The data graph should include all the ontology axioms related to the 
data and especially all the rdfs:subClassOf triples in order for SHACL 
to correctly identify class scopes and core SHACL constraints. If such 
triples are missing, the validation could report false violations or 
miss to report some violations."

I don't see anything about carrying subclasses in the shapes graph that 
would be applied to the data graph. I can vaguely imagine a shapes graph 
that (re-)defines class relationships in the data graph, but I don't 
think we've entertained that.

kc

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

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Monday, 9 May 2016 19:39:27 UTC