W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > May 2016

Re: ISSUE-105: Prefixes in SPARQL fragments

From: Eric Prud'hommeaux <eric@w3.org>
Date: Sun, 8 May 2016 06:20:18 -0400
Message-ID: <CANfjZH3yFJJ-a7Dqkpqt9BEFAz+WfhqChXmjMMJkb2YD+m9baA@mail.gmail.com>
To: Karen Coyle <kcoyle@kcoyle.net>
Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
On May 7, 2016 6:36 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:
>
> A better explanation, perhaps:
>
>
> On 5/6/16 10:13 PM, Holger Knublauch wrote:
>>>
>>> At the same time, I understand the immediate need. I think we need,
>>> however, to clarify what we expect in the pre-SHACL process on both
>>> shapes and data graphs. Already there is the decision that rdf:type
>>> statements must be explicit in both graphs, even though that implies
>>> some pre-processing.
>>
>>
>> Usually no pre-processing of the data graph is needed. The language is
>> designed so that it walks the subclass hierarchy in a couple of
>> important places, making the (expensive and often even impractical)
>> pre-processing of rdf:type triples unnecessary.
>
>
> The requirement that rdf:type declarations be explicit, because no
inferencing will be done on domains and ranges in the data graph's defined
vocabulary, implies that in some cases the data graph will need to be
pre-processed so that the rdf:type declarations are there in the graph. We
have talked about this. SHACL has some expectations, and how one gets ones
data to meet those expectations is out of band.
>
> How does SHACL walk the subclass hierarchy unless that information is in
the data graph? Carrying those declarations in a data graph, in my
experience, would be unusual.

What if validation takes a list of data graphs instead of a single graph?
One could stick the supplemental inferences from preprocessing into a
separate graph and thus not alter or have to copy the initial data.

> kc
>
> --
> Karen Coyle
> kcoyle@kcoyle.net http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet/+1-510-984-3600
>
Received on Sunday, 8 May 2016 10:26:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:33 UTC