- From: Tom Johnson <johnson.tom@gmail.com>
- Date: Thu, 17 Mar 2016 16:23:49 -0700
- 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>
- Message-ID: <CAJeHiNG6rOOwPwD27GbLutS4DMQ+8cbWX_a72M9Lqh6TiXM92w@mail.gmail.com>
This brings us back to a week ago up-thread: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0082.html Per this comment, I don't think this is a purely conceptual problem. If a dataset is a Fundamental concept that can't be ignored in defining SHACL, no problem. I'm somewhat skeptical of this, but I agree with all your points that this isn't a hard implementation, it's easily supported in all major existing RDF environments, etc... The problem I see exists closer to the SHACL language. When authoring a shapes graph, how can I ensure that I will be able to run it against the data graphs of my choice? - Tom On Thu, Mar 17, 2016 at 4:16 PM, Holger Knublauch <holger@topquadrant.com> wrote: > A dataset is a conceptual entity that can be implemented in many ways. One > implementation may retrieve certain graphs on-the-fly via an LDP server. > That's an implementation detail to me. But SPARQL requires datasets, so how > can we pretend they don't exist? > > Holger > > > > On 18/03/2016 9:06, Tom Johnson wrote: > > 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> 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>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>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> >>> 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://dbpedia.org, >>> http://rdfunit.aksw.org, >>> > http:// <http://aligned-project.eu>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> >>> 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> >> http://aksw.org/Groups/KILT >> >> >> > > > -- > -Tom Johnson > > > -- -Tom Johnson
Received on Thursday, 17 March 2016 23:24:58 UTC