W3C

RDF Data Shapes Working Group Teleconference

02 Jul 2015

Agenda

See also: IRC log

Attendees

Present
Arnaud, kcoyle, pfps, aryman, dimitris, hknublau, TallTed, labra
Regrets
ericp, simonstey
Chair
Arnaud
Scribe
kcoyle

Contents


<scribe> scribenick: kcoyle

Admin

<Arnaud> PROPOSED: Approve minutes of the 25 June Telecon: http://www.w3.org/2015/06/25-shapes-minutes.html

<aryman> +1

RESOLUTION: Approve minutes of the 25 June Telecon: http://www.w3.org/2015/06/25-shapes-minutes.html

<pfps> The minutes look OK, but it took me quite a bit of effort to figure out that the change was actually made to ISSUE-72. I got an old version days after the change was made.

Next meeting 9 July

Arnaud: Should we go to lighter schedule for summer? hmmm, we're already behind, let's go on!

<pfps> ok by me :-(

SHACL FPWD

<pfps> What document are we discussing?

Arnaud: SHACL 1st public working draft - where are we?
... what would it take to publist 1st draft?
... should makr issues that are open; status can be made clear
... s/makr/mark

aryman: would like to have 2 week lead before it goes public so group can review a stable draft

<pfps> Editor*s*???

pfps: not sure when I got to be an editor... am I?

aryman: thought Peter ahd Holger working together

pfps: Not so

<hknublau> +q

pfps: things that need to be in place:
... well-founded semantics
... has to have notion of what direction is
... latter is not yet true
... what would it take? we still have issue that would negate bulk of the document: access to shape graph
... even more important, recursive shapes, which is not on our radar (not issue-22)

hknublau: so many open issues that document is somewhat frozen; would welcome other editors

<pfps> the issue that needs to be worked in is ISSUE-66 non-convergence

hknublau: need to get shape graph issue out of the way

<pfps> ISSUE-68 should also be resolved, and this one can be done by Holger

pfps: issue 68 could be done; editorial

hknublau: am looking at that; more than just editorial

pfps: issue 68 is just missing from spec, doesn't need decisions. Go ahead and add it
... needs to be done for 1st public working draft

<pfps> pre-binding is a significant part of the document and needs to be done before FPWD

<pfps> There are holes that can be filled in later and there are sink-holes that can consume an entire document.

Arnaud: FPWD will get more comments from folks outside the immediate group
... Holger - time estimate?

hknublau: can put in placeholder in the next few days

Arnaud: re:annotating the spec with the open issues -- is there still a respec problem?

hknublau: respec adds numbering; so I'm adding link to documents; any help welcome

aryman: is it worth freezing the doc the way it is now; do a round of review? is it stable? would a detailed review be good now?

<pfps> The document has been stable for a while now.

hknublau: has been stable for a while; and reflects my prototype

aryman: can there be revision bars on changes? makes it easy to see what's changed

<pfps> There used to be a way to see revision changes in W3C WDs. That was very useful. Source diffs are very much less useful.

Arnaud: maybe a history of changes section at the end for significant changes
... Holger will create a marked draft that represents current stable version

<pfps> Another problem with ReSpec is that it is not easy to see old versions of the document - the Wiki is very much better in this regard.

ISSUE-47: Can SPARQL-based constraints access the shape graph, and how?

<trackbot> Notes added to ISSUE-47 Can SPARQL-based constraints access the shape graph, and how?.

Arnaud: had 3 different proposals; this should be a yes/no question: access or not?

<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/0159.html

<aryman> what picture? link pls?

hknublau: 2 ways that SHACL can be used with SPARQL

<aryman> aha

hknublau: 1- dataset with shacl; enterprise system with controlled set of named drafts and sparql functions; a kind of closed world
... 2 - sparql end point and shacl engine live in different environments; no control over endpoint
... solution 1: restrict language to only features that can be supported with sparql
... solution 2: go beyond limitation of sparql endpoints by encouraging implements to implement "shacl endpoint" where you send shacl graph to a server that applies shacl constraints on the graph
... solution 2 would be ideal, having shacl implemented natively in databases
... sparql solution is bridge until solution 2 is available

<pfps> There was quite an echo.

hknublau: implement by allowing different types of shacl language; create a subset that is not supported by sparql
... would not implmenet custom functions; requests outside of the subset could be detected

pfps: view: access to shpaes graph gets you a little but prevents a lot of functions

<Dimitris> +q

pfps: shacl engine allows access to graph; not true that blank nodes are problematic for this proposal; well-handled by sparql endpoints
... access to shapes graph when evaluating constraints on data graph permits a jparticular execution methodology that is inefficient
... because of top-down implementation there is redundancy that can be costly

<hknublau> +q

pfps: gain little by access to shapes graph except for recursion, which you may have to give up; preferably where you cannot load data locally, e.g. dbpedia

Dimitris: agree with Peter; blank nodes not a problem; looking for use case for access beyond core language

hknublau: blank nodes not handled because not persistent; only work locally;

<Dimitris> +q

hknublau: peter's proposal would be a re-write of the document, and may have efficicency issues -- so details will be needed.

<pfps> The details have been worked out *and* implemented!

hknublau: also need alternative to shapes graph access

<aryman> the SHACL engine of course needs to access the SHACL program, so are we talking about having the SHACL in the same dataset as the data graph?

aryman: shacl engine obviously needs to read the shacl program - are we debating whether shacl program in same dataset as datagraph?

pfps: if shacl control graph is in dataset, then you can access it using sparql and everything is easier; but you might say that the shacl control graph is not part of target dataset, but is accessible using some sparql extension

Dimitris: suggestion was to use holger's proposal but limit some things outside of core until we get use cases to support

Arnaud: let's stick just to the two options
... straw poll (binary) or third way, to have it as an optional feature (which isn't great for interoperability)

<hknublau> +q

hknublau: third option is what I am proposing
... it's an optional feature

aryman: from a pragmatic point of view if we have close tie between shacl and sparql engine we will limit shacl use; needs to be the shape graph, but cannot require that shape graph be in same dataset as dataset

<Arnaud> STRAWPOLL: a) allow access to the shape graph, b) do not allow access to the shape graph, c) allow access to the shape graph as an optional feature

<hknublau> a +0.5 b -1 c +1

<aryman> a:-1,b:+1,c:-1

<pfps> a: -1, b: +1, c: maybe - it really depends on how it plays out - the version that Holger appears to be promoting would be a -1

a) +1 b) -1 c) +1

<Labra> a: -1, b: +1, c: -0.5

<Dimitris> a)-0.9, b)+1, c)0

<TallTed> a +0.5, b -0.5, c +0.5

<ericP> -.5, +1, -.5

<hknublau> +q

<aryman> I'm OK with the semantics being expressed in terms of the SHACL graph

hknublau: need to keep in mind that some of this is implementation details

<pfps> If in c access to the SHACL control graph was *truly* optional, and not specified throughout the document, then it would be much more palatable

<hknublau> +q

aryman: we should focus on defining things for remote sparql end point case first, since that's the most important case; a matter of priorities

<pfps> I agree that there is currently only *one* worked-out specification for SHACL. It is https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql

Arnaud: spec would have to allow that you may not have access
... discuss online - what would it take for option c to work

pfps: there is only one worked out proposal, and that is not current editor's draft

<hknublau> +q

pfps: current editor's graph has holes in it; other doc (linked above) is fully worked out
... and is the way it is done in startdoc ICV

aryman: would like to see compelling use case for not having access to graph;

<pfps> Having an implementation is not sufficient to show well-foundedness.

aryman: Peter asserts that the spec isn't founded; but there is an implementation, so we should focus on areas where spec needs work; tighten spec before we add features

hknublau: feature is already there, and isn't a big issue

<hknublau> +q

aryman: that it is in the spec has implications for developers

hknublau: right hand picture already works
... if you want to run against remote endpoint, that works. option B would require re-writing draft

<pfps> There is lots of noise.

aryman: recursion should not be linked to access to data graph; there are lots of things tied together here that are muddying the discussion

<pfps> Both a and b use SPARQL as their specification language. Both a and b could have the core implemented without access to a full SPARQL implementation.

<aryman> a triple API is not a SPARQL endpoint

<aryman> it must be possible to implement core SHACL without SPARQL

pfps: "sparql" here means any access to the data graph

kcoyle: should we really call it sparql if it doesn't acutally use sparql but has its own software

<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Jun/att-0159/SHACL-Engines.png

<hknublau> +q

<aryman> question: does the SHACL graph just contain the SHACL program, or are you allowing arbitrary other triples in it?

aryman: in the shapes graph, are you assuming that the graph is closed, that it just contains what is in the shacl language?
... e.g. xslt - xslt doc is an xml document, can be used to get to arbitrary other data

hknublau: main reason to access it is to query the shapes; uses formalisms eg classes, members of rdflist. Those are stored in the shapes graph

<pfps> It would be nice to get more people involved in the discussion. There are at least two WG members who were not present today.

Arnaud: that's enough for today

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 25 June Telecon: http://www.w3.org/2015/06/25-shapes-minutes.html
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2015/07/15 21:39:12 $