Re: ISSUE-23: Where should we query for class and subClassOf?

Holger/Irene,

One of the use cases we'd like to support is using SHACL to validate
SHACL. This means we need a way to distinguish data from metadata.
Looking for metadata in the data graph isn't necessarily fatal. We
need more discussion on this topic. The spec must be clear on this
point.

-- Arthur

On Tue, Jan 19, 2016 at 8:56 PM, Irene Polikoff <irene@topquadrant.com> wrote:
> I agree that requiring applications to copy triples from one graph to another before they can submit to SHACL engine complicates things and it is a concern.
>
> Can it be assumed as a default that boy shapes and data graph are queried and then, for cases where performance of this may be an issue, have a way to set an indicator that only shapes graph should be queried?
>
> May guess is that this is not often will be a performance issue. Looking for parent classes of a given class is an easy query even for a large dataset.
>
> Sent from my iPhone
>
>> On Jan 19, 2016, at 8:09 PM, Holger Knublauch <holger@topquadrant.com> wrote:
>>
>> (I predict that the separation between shapes and data graph will become a FAQ topic for SHACL. It may have been better to leave this topic out in version 1 of the standard, as many users will topple over it. Such things may break the standard's adoption because they complicate everything. In the end, the main benefit of having a shapes graph is optimizing performance (so that the data graph is not polluted), yet this may be considered premature optimization as engines can probably take care of this themselves.)
>>
>> Anyway, your specific suggestion MAY work for me, as the shapes graph is a conceptual/logical entity only and engines may inject any number of triples into the shapes graph prior to validation. This doesn't make life easier though, so I am not sure.
>>
>> Two issues come to my mind:
>>
>> 1) if we assume the rdfs:subClassOf triples reside in the shapes graph only, then the user/engine needs to take care to consider extensibility: the data graph may include extensions of the core ontology that a shapes graph was developed against. For example someone may create a subclass ex2:Cat while the shape only knows about ex1:Animal. To prepare validation, some agent would need to make sure that ex2:Cat rdfs:subClassOf ex1:Animal is visible to the shapes graph.
>>
>> 2) sh:class currently looks at the data graph. If we change the behavior of sh:scopeClass then we arguably would also need to change sh:class to walk the shapes graph.
>>
>> Holger
>>
>>
>>> On 20/01/2016 4:38 AM, Arthur Ryman wrote:
>>> While reading the spec I noticed the following statement:
>>>
>>> "To determine class membership, the rdf:type and rdfs:subClassOf
>>> triples are queried in the data graph."
>>>
>>> However, querying the data graph for class and subclass information is
>>> inconsistent with the example SPARQL for determining which shapes are
>>> classes:
>>>
>>> "As syntactic sugar for the scenario above, SHACL includes a rule that
>>> if a class is also a shape (in the shapes graph), then the
>>> sh:scopeClass triple pointing at itself can be omitted. This rule is
>>> illustrated by the following SPARQL CONSTRUCT query, which may be
>>> executed over the shapes graph prior to validation, to produce the
>>> implicit sh:scopeClass triples."
>>>
>>> CONSTRUCT {
>>> ?class sh:scopeClass ?class .
>>> }
>>> WHERE {
>>> ?class rdfs:subClassOf*/rdf:type rdfs:Class .
>>> ?class rdfs:subClassOf*/rdf:type sh:Shape .
>>> }
>>>
>>> I propose that in both cases we query the shapes graph, NOT the data graph.
>>>
>>> Recall that we expect the application to provide a shapes graph and a
>>> data graph as input to the SHACL validator. Therefore, the application
>>> can always copy any rdfs:Class and rdfs:subClassOf triples into the
>>> shapes graph. Although RDF does not require class definitions to be
>>> separated from data instances, in practice these are often separated.
>>> Both shapes and classes are more properly regarded as metadata than
>>> data.
>>>
>>> -- Arthur
>>
>>
>

Received on Wednesday, 20 January 2016 03:47:40 UTC