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: Mon, 21 Mar 2016 20:32:42 +0200
Message-ID: <CA+u4+a3q=smCjGF=69dZfyqBQ72q+cpsYbcd7ZtP8W9KNK0+Lg@mail.gmail.com>
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Cc: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
RDFUnit does work on endpoints but it's not a complete shacl
implementation.

In short, i see filters and qualified cardinality as the main problem for
enabling shacl on sparql endpoints.
Filters could be evaluated after the constraints as Peter noted in another
thread but haven't found a way for QCs yet.

Peter, do you have any suggestions for handling QCs in this case?

In any case this is independent of this issue and related to the
$shapesGraph variable resolution.
$shapesGraph is optional and people who use it outside of core will be
aware that they are not interoperable.
On Mar 21, 2016 19:44, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
wrote:

> I think that Dimitris's implementation does work on endpoints.
>
> The implementation that I am putting together will work on endpoints as
> well.
>
> peter
>
>
> On 03/21/2016 04:12 AM, Dimitris Kontokostas wrote:
> > Found it, https://www.w3.org/2015/08/27-shapes-minutes.html#resolution03
> > the resolution does not say this but iirc the discussion (which is not
> 100%
> > scribed) was talking about bnodes and how they can be identified with a
> remote
> > call vs in-memory.
> > ARQ and Sesame do something clever with bnodes which is not the case for
> all
> > sparql engines but I am not trying to re-open the old issue, only trying
> to
> > close this one using that resolution
> >
> > I propose we close this issue as: SHACL does not assume that the data
> graph is
> > an RDF dataset as addressed by the current editor's draft
> > This of course allows people to use datasets but SHACL doesn't take any
> > special care in this case
> >
> >
> > On Mon, Mar 21, 2016 at 12:59 AM, Holger Knublauch <
> holger@topquadrant.com
> > <mailto:holger@topquadrant.com>> wrote:
> >
> >     On 18/03/2016 18:38, Dimitris Kontokostas wrote:
> >>
> >>     On Fri, Mar 18, 2016 at 9:41 AM, Peter F. Patel-Schneider
> >>     <<mailto:pfpschneider@gmail.com>pfpschneider@gmail.com
> >>     <mailto: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
> >
> >     The resolution that we made a while ago was to not require support
> for the
> >     SPARQL endpoint protocol. Note that this is different from the
> question of
> >     in-memory vs database. It means that implementations can still work
> >     against databases, e.g. via an API such as ARQ or Sesame (for which
> all
> >     major databases provide drivers for), while the SPARQL endpoint
> protocol
> >     is too limiting for what SHACL needs to do.
> >
> >     Holger
> >
> >
>
>
Received on Monday, 21 March 2016 18:33:17 UTC

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