RDF Data Shapes Working Group Teleconference

19 Oct 2016


See also: IRC log


simonstey, AndyS, Arnaud, hknublau, marqh, Dimitris, kcoyle, hsolbrig, pano, Labra, TallTed, ericP


<scribe> scribe: simonstey


<Arnaud> PROPOSED: Approve minutes of the 11 Oct 2016 Telecon: http://www.w3.org/2016/10/11-shapes-minutes.html

<hknublau> +1


RESOLUTION: Approve minutes of the 11 Oct 2016 Telecon: http://www.w3.org/2016/10/11-shapes-minutes.html

Arnaud: based on Jose's email, I propose to change our weekly calls back to Wednesday
... eventhough it's not optimal for all of us, it's not as bad as tuesday

<Arnaud> PROPOSED: Move weekly calls back to Wednesday


<ericP> +1

<kcoyle> +1

<Labra> +1

<Dimitris> +1

<pano> +1

<AndyS> +1

<marqh> +1

<hknublau> +1

<hsolbrig> +1

RESOLUTION: Move weekly calls back to Wednesday

Arnaud: I've not forgotten about my action

Disposal of raised issues

<Arnaud> PROPOSED: Open ISSUE-190, ISSUE-191


<trackbot> issue-190 -- Identifying the shapes in a SHACL Full shapes graph -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/190


<trackbot> issue-191 -- Should the value types of parameters be constraints -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/191

<hknublau> +1


<kcoyle> +1

<Dimitris> +1

<Labra> +1

<hsolbrig> +1

<pano> +1

<ericP> +1




<trackbot> action-43 -- Mark Hedley to Take a read through the spec and raise specific terminology issues as needed -- due 2016-10-04 -- OPEN

<trackbot> http://www.w3.org/2014/data-shapes/track/actions/43

Arnaud: marqh took an action to read through the spec to check whether there are still parts that would need to be fixed
... so marqh, what's the outcome?

marqh: I picked up 2 starting points
... 1) where the term node and resource is being used
... 2) SPARQL terminology

<hknublau> BTW I appreciate the specific pull requests - makes editing job easier and clearer.

marqh: e.g., solution, binding, solution set (?), etc.

<AndyS> "Solution Mapping" :: https://www.w3.org/TR/sparql11-query/#sparqlSolutions

marqh: so from my perspective, I don't feel like I've already completed my action
... I think another pass would be required

Arnaud: I'm totally fine with keeping the action open

kcoyle: I had actually closed the issues pfps complained about and I haven't reopened them since

<AndyS> A 'binding' is a pair (variable, RDF term) in a solution mapping but is not defined formally in SPARQL and is used loosely in other ways.

kcoyle: I certainly have comments but don't think they are worth being issues

Arnaud: everyone should use whatever he/she prefers to work with

<kcoyle> https://docs.google.com/document/d/1O24vnnZuTWQgi2-U_-lnY-IjV9EbRyxNtrYC3zq2pnM/edit

<kcoyle> see section 3, which has not been completed

Arnaud: not sure whether cloning the spec on google docs makes sense
... all changes made on google docs would have been replicated on github

ericP: I haven't found any issues wrt. using google docs for editing the spec

marqh: there may be some value in following up on pfps comment on closing issue 142
... if people are not familiar with using github I would encourage them to have a look at github's web interface

hsolbrig: I'm following up on advocating using github

TallTed: I'm advocating against using google docs

Arnaud: if the editors take the responsibility to keep the documents consistent
... they can use whatever they prefer

kcoyle: with github I can make edits
... but there is no discussion
... are there any other alternatives?
... I have dozens of comments on e.g., 2 paragraphs
... how should we handle those?

Arnaud: other groups are using github issues

kcoyle: How would I refer to specific parts of the spec?
... line numbers?

Arnaud: lets add a link to the doc to the wiki

ericP: one approach would be to have all the conversation on the google doc
... but make changes first to github

Dimitris: kcoyle was not changing text but suggesting it
... only if an editor approves the changes, they make it to github

Arnaud: [mentions gerrit (?) as alternative]
... it's based on git

<pano> it is possible to make line comments on PR's on github.com though

Arnaud: just for the record, I once lost all access rights to google docs..



<trackbot> issue-131 -- The definition of sh:hasShape has errors and holes -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/131

Arnaud: any news?

hknublau: I wrote down a proposal explaining how mentioned issues were addressed
... for now, I think the function is well behaving

Arnaud: are we ready to close the issue per hknublau's proposal?

Dimitris: one issue was requiring having access to the shapes graph
... I'm not blocking a resolution but I'm not happy with closing it

hknublau: there is really no need for accessing a shapes graph variable

kcoyle: I've a general comment about SHACL full
... as it isn't written as being a general purpose language
... but more as being a SPARQL extension

Arnaud: to be fair, we kinda agreed to that.. i.e., using SPARQL as our execution language
... is the question of arguments critical to the resolution of issue-131?

<Dimitris> summarising my points is that I think sh:hasShape is not needed in general in SHACL in general

Arnaud: it might be a progress to close the general issue and reopen a new one having a more narrower scope

hknublau: the argument has been removed because it was just the URI of the shapes graph
... and a shapes graph might not have a URI

Arnaud: so a shapes graph might not be addressible?

Dimitris: I still think the hasShape function makes SHACL way more complicated than necessary
... [explains changed nature of hasShape]
... currrently only sh:node is defined using hasShape

hknublau: there are def. use cases for hasShape

<Dimitris> we can alredy test members of a list with property paths now

hknublau: especially for expressing things we couldn't express otherwise

<hknublau> How to test that all members have a given shape?

<Dimitris> with sh:path

<Dimitris> and sh:shape

kcoyle: what Dimitris said makes sense to me.. maybe we should have a strawpoll?

<Arnaud> STRAWPOLL: Close ISSUE-131, a) as is, b) removing sh:hasShape

<kcoyle> a) -.8 b) +1

<Dimitris> a) -.9, b) +1

<Labra> a) -0.9 b) +0.9

<hsolbrig> a) 0 b) +1

a) 0 b) +0.5

<ericP> a) 0 b) +1

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

c) +1

<ericP> c) 0

<kcoyle> c) -.99

<hsolbrig> c) 0

<Dimitris> c) -0

<Arnaud> how about c) as is but optional

<Arnaud> PROPOSED: CLose ISSUE-131, removing sh:hasShape

<kcoyle> +1

<hknublau> -0.9

<Dimitris> +1

<ericP> +1

<pano> 0

<Labra> +1

<AndyS> 0

<hsolbrig> +1


<marqh> 0

RESOLUTION: Close ISSUE-131, removing sh:hasShape

<TallTed> +1

Filter and focus nodes

kcoyle: Dimitris and I were going through the spec, looking for places where filters/focus nodes are used

Dimitris: what do we do with targets? how targets are used esp. wrt. to their sorrounding shape
... if a shape is being referenced from another shape

kcoyle: I think we need issues for that

ISSUE-92: additive repeated properties


<trackbot> issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/92

Arnaud: it actually points to a gap in SHACL
... we now have sh:partition

ericP: hknublau and I discussed this a bit

<kcoyle> eric's email: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Oct/0109.html

<ericP> Mapping of ShEx to SHACL

ericP: this document explains how one can use ShEx for writing SHACL
... I changed the semantics of sh:partition to fit ShEx semantics

hknublau: how would this feature be published?
... I'm afraid that we're running out of time

ericP: we do have tests&test suite already done

Arnaud: I feel that we owe it to the ShEx community to not drop that feature

hknublau: I'm absolutely sympathetic in building bridges here

<kcoyle> section 4.8.3

Arnaud: ericP, would it be possible for you to replace Arthur's description on sh:partition with yours?


hknublau: I still hope that this ends up as being an optional feature

kcoyle: at the moment, this is in core

ericP: we could just say that this is an optional feature
... and make sure the test suite treats it as such

Arnaud: [discusses how optional features influence publication of specs]
... we leave the issue open for now

ISSUE-140: Individual validation


<trackbot> issue-140 -- SHACL needs to support validation of individual nodes -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/140

ericP: I was working on the other stuff, so no progress for now

ISSUE-177: abstract-syntax-disconnected


<trackbot> issue-177 -- Abstract Syntax is disconnected from concrete syntax -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/177

ericP: what are we going to test in terms of error handling?
... we could test the content of errors
... as soon as I know it, I could put it in the AS

Dimitris: to check true/false only

kcoyle: I can recall another one you mentioned Dimitris
... having a validation report also for things that validate correctly

Dimitris: that's about representation

ericP: the problem is that we have a certain structure and we have a certain notion of validity
... but we don't have a specific combination of schema&data that we can hand to an implemention

hknublau: we do have that!

Dimitris: the spec says that for every violated core constraint a result is returned

Labra: [mentions (performance) issues of requiring to return all errors]
... and you also don't know whether shape validation passed
... or whether it just failed

kcoyle: specific messages are only returned in SHACL full

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 11 Oct 2016 Telecon: http://www.w3.org/2016/10/11-shapes-minutes.html
  2. Move weekly calls back to Wednesday
  3. Open ISSUE-190, ISSUE-191
  4. Close ISSUE-131, removing sh:hasShape
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/10/27 00:05:15 $