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: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
Date: Fri, 18 Mar 2016 10:38:14 +0200
Message-ID: <CA+u4+a1iq2CNscfoP_GZ2joRBAGJaUd4qfXG=Mx7n3AHoo9+2g@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Tom Johnson <johnson.tom@gmail.com>, Holger Knublauch <holger@topquadrant.com>, RDF Data Shapes Working Group <public-data-shapes-wg@w3.org>
On Fri, Mar 18, 2016 at 9:41 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> If it is always possible to construct the dataset, then I don't see a
> problem
> either.  However, is this always possible?  For example, a user who is just
> trying to validate a graph may not have permissions to create or modify a
> dataset.
>

iirc there was a resolution on supporting only in-memory validation (not my
favorite and cannot find it), e.g. full shacl may not run on remote
 datasets e.g. sparql endpoints.
With this in mind an implementation could just copy the shapes & data graph
in memory and perform the validation there


>
> peter
>
>
> On 03/17/2016 04:50 PM, Tom Johnson wrote:
> > That seems okay to me. In this case, wherever the SHACL spec refers to a
> > Dataset, the main requirement should be that it is clear how the
> referenced
> > Dataset is constructed from the Shapes graph and the Data graph. The main
> > point of the specs use, then is that a SHACL validation requires two
> graphs:
> > shapes & data. All of the rest of the handling re: SPARQL Datasets can
> then be
> > abstracted away by implementers if desired.
> >
> > - Tom




-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig & DBpedia Association
Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://
http://aligned-project.eu
Homepage:http://aksw.org/DimitrisKontokostas
Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Friday, 18 March 2016 08:39:10 UTC

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