Re: New Terminology Section

On 10/05/2016 5:36, Karen Coyle wrote:
>
>
> 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.

To avoid confusion, SHACL has two constructs where rdfs:subClassOf 
triples matter, and both are in the data graph:

- sh:class
- sh:scopeClass

In neither of them any form of inferencing is needed - I would be the 
last person on this mailing list to make SHACL require inferencing. All 
we require is *querying* or pattern matching like SPARQL does it, and 
SPARQL provides the rdfs:subClassOf* construct as a convenience, while 
the same can easily be programmed in any other execution language.

Holger


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

Received on Monday, 9 May 2016 23:32:47 UTC