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

Re: shapes-ISSUE-130 (rdf dataset assumption): SHACL should not assume that the data graph is in an RDF dataset [SHACL Spec]

From: Tom Johnson <johnson.tom@gmail.com>
Date: Thu, 17 Mar 2016 16:06:20 -0700
Message-ID: <CAJeHiNE1zCv-GJzurY+BFor5=P4XEVLhaz76T6JNiSCzvdMAcQ@mail.gmail.com>
To: Holger Knublauch <holger@topquadrant.com>
Cc: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
Datasets seem fine to me, as an implementation detail, but my main context
for using SHACL would be to validate graphs from one of two contexts:

  - Linked Data Platform RDFSources; i.e. I have an existing shapes graph,
and I want to validate a number of graphs grabbed via HTTP GET.
  - Existing in-memory graphs. (in this case, serializing to a file is
always an option).

In either of these cases specifying the Dataset construct at the SHACL
level seems unwieldy. When writing a shapes graph, I need to know how the
specific engine will handle my URI/File/native-graph input.

I don't have a specific proposal to improve things, but the idea that
SHACL's behavior is undefined except when my shapes graph and data graph
already exist within the same SPARQL Dataset is concerning.

- Tom

On Thu, Mar 17, 2016 at 3:49 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> On 18/03/2016 1:49, Dimitris Kontokostas wrote:
>
>
>
> On Thu, Mar 17, 2016 at 3:20 PM, Peter F. Patel-Schneider <
> <pfpschneider@gmail.com>pfpschneider@gmail.com> wrote:
>
>> The diff seems to indicate that functions still work only over datasets,
>> although there is a TODO indicated.
>
>
> I was waiting for Holger to wake up and clarify this but you are right
>
>
> SPARQL in general relies on datasets, e.g. in the GRAPH keyword. As soon
> as we talk about arbitrary SPARQL queries (e.g. in sh:sparql constraints or
> functions), datasets need to be in the picture.
>
> I maintain my position that we would be making our lives easier if we were
> simply talking about datasets, acknowledging that these datasets may only
> exist for the duration of a SHACL execution and contain the data graph (and
> the shapes graph) only. There is nothing conceptually difficult here,
> neither difficult to implement.
>
> Holger
>
>
>
>
>
>> Two "or dataset"s were also removed -
>> making the dataset optional is probably benign.
>>
>> As far as $shapesGraph goes, wording along the lines of "can be used to
>> access
>> the shapes graph" would seem to work, but would need some explanation
>> along
>> the lines of "If the shapes graph is a named graph in the same dataset as
>> the
>> data graph then it can be accessed using its name in the dataset.
>> Otherwise a
>> SHACL engine would need to provide an alternative way to access the
>> shapes graph."
>>
>
> tried to fix all your comments in a second commit here
>
> https://github.com/w3c/data-shapes/commit/a0a52a4472d807683abf7cf104079f35272f27df
>
>
> this is a merge of both commits but also includes a few other editorial
> fixes
> https://github.com/w3c/data-shapes/compare/editorial-dk
>
> apologies for sending commits but I am not yet comfortable to commit to
> the main branch
>
> Best,
> Dimitris
>
>
>
>>
>>
>> peter
>>
>>
>> On 03/17/2016 02:04 AM, Dimitris Kontokostas wrote:
>> > I removed all mentions of dataset in the text that imply that
>> validation works
>> > on RDF datasets
>> >
>> https://github.com/w3c/data-shapes/commit/fa2d99fd61a473d14eef9cee57c0db1c61e03684
>> >
>> > One thing left to decide and close this issue  is how to refer to the
>> > '$shapesGraph" variable. right now we have variations of the following
>> in the spec
>> > "$shapesGraph ... a named graph IRI that contains the the shapes graph"
>> >
>> > reading the sparql spec, named graphs imply an RDF dataset:
>> > https://www.w3.org/TR/sparql11-query/#namedGraphs
>> >
>> > even if we remove the "named" and refer to them as just graphs, SPARQL
>> uses
>> > the "GRAPH" keyword in the "Querying the Dataset" section
>> > https://www.w3.org/TR/sparql11-query/#queryDataset
>> >
>> > so, do we still have an implicit assumption that validation works on
>> RDF datasets?
>> >
>> > Since we already have a resolution on $shapesGraph I see the following
>> options:
>> > a) we accept the edits as they are now in the spec and close this issue
>> > b) we try to weaken further the connection and change occurrences of
>> "named
>> > graph" to "graph"
>> > c) since this is  sparql-specific issue, we can add a disclaimer in
>> section 1.2
>> >
>> > regarding how a SHACL validation engine wraps graphs to perform
>> validation, it
>> > can be an implementation detail
>> >
>> > Dimitris
>> >
>> >
>> > On Wed, Mar 9, 2016 at 9:35 AM, Holger Knublauch <
>> holger@topquadrant.com
>> > <mailto: <holger@topquadrant.com>holger@topquadrant.com>> wrote:
>> >
>> >     Yes, you may have a point there - in cases like the default graph
>> we need
>> >     to make sure that the system knows which subject to look for the
>> >     sh:shapesGraph triples. This is probably just a URI parameter.
>> >
>> >     (There are so many edit suggestions open right now that I am looking
>> >     forward to sharing the workload with a second editor, now that
>> Arthur has
>> >     left; yes I have a day job too.)
>> >
>> >     Holger
>> >
>> >
>> >     On 8/03/2016 11:02, Tom Johnson wrote:
>> >>     > An RDF dataset is a purely conceptual entity. Many APIs implement
>> >>     Dataset. Any Graph can be wrapped into a Dataset for execution,
>> even if
>> >>     that Dataset is just virtual and only has a single graph in it.
>> >>
>> >>     Reading the quoted text, this doesn't seem to hold. The "data
>> graph"
>> >>     links to the "shapes graph" via a triple with its graph name as the
>> >>     subject. Many graphs do not have such a name (even those that are
>> within
>> >>     Datasets; i.e. default graphs).
>> >>
>> >>     Does SHACL provide a mechanism for connecting such a graph to a
>> shapes
>> >>     graph? If not, how does wrapping the graph in a dataset within the
>> >>     implementation help a SHACL user make this connection?
>> >>
>> >>     - Tom
>> >>
>> >>     On Mon, Mar 7, 2016 at 3:00 PM, Holger Knublauch <
>> holger@topquadrant.com
>> >>     <mailto: <holger@topquadrant.com>holger@topquadrant.com>> wrote:
>> >>
>> >>         An RDF dataset is a purely conceptual entity. Many APIs
>> implement
>> >>         Dataset. Any Graph can be wrapped into a Dataset for
>> execution, even
>> >>         if that Dataset is just virtual and only has a single graph in
>> it.
>> >>
>> >>         Holger
>> >>
>> >>
>> >>
>> >>         On 8/03/2016 2:45, RDF Data Shapes Working Group Issue Tracker
>> wrote:
>> >>
>> >>             shapes-ISSUE-130 (rdf dataset assumption): SHACL should not
>> >>             assume that the data graph is in an RDF dataset [SHACL
>> Spec]
>> >>
>> >>             http://www.w3.org/2014/data-shapes/track/issues/130
>> >>
>> >>             Raised by: Peter Patel-Schneider
>> >>             On product: SHACL Spec
>> >>
>> >>             """4. Declaring the Shapes Graph
>> >>
>> >>             A data graph MAY link to one or more shapes graphs via the
>> >>             property sh:shapesGraph. The subject of this predicate
>> must be
>> >>             the graph resource, i.e. the name of the data graph in the
>> >>             dataset. The objects of this predicate must be IRI nodes,
>> >>             pointing at a named graph in the dataset. Tools may use
>> this
>> >>             information to determine which shapes graph to use for
>> >>             validation. If present, tools SHOULD transitively follow
>> any
>> >>             links from the shapes graph via the predicate owl:imports
>> to
>> >>             other graphs and use the resulting union graph as
>> parameter to
>> >>             the validation process."""
>> >>
>> >>             This assumes that the data graph is in an RDF dataset.
>> SHACL
>> >>             validation should work on data graphs that are not in an
>> RDF
>> >>             dataset.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     --
>> >>     -Tom Johnson
>> >
>> >
>> >
>> >
>> > --
>> > Dimitris Kontokostas
>> > Department of Computer Science, University of Leipzig & DBpedia
>> Association
>> > Projects: http://dbpedia.org, <http://rdfunit.aksw.org>
>> http://rdfunit.aksw.org,
>> > http://http://aligned-project.eu < <http://aligned-project.eu/>
>> http://aligned-project.eu/>
>> > Homepage:http://aksw.org/DimitrisKontokostas
>> > Research Group: AKSW/KILT <http://aksw.org/Groups/KILT>
>> http://aksw.org/Groups/KILT
>> >
>>
>>
>
>
> --
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia
> Association
> Projects: <http://dbpedia.org>http://dbpedia.org, http://rdfunit.aksw.org,
> http:// <http://aligned-project.eu/>http://aligned-project.eu
> Homepage: <http://aksw.org/DimitrisKontokostas>
> http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>
>
>


-- 
-Tom Johnson
Received on Thursday, 17 March 2016 23:07:31 UTC

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