See also: IRC log
<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
+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
+1
<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
<Arnaud> PROPOSED: Open ISSUE-190, ISSUE-191
issue-190
<trackbot> issue-190 -- Identifying the shapes in a SHACL Full shapes graph -- raised
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/190
issue-191
<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
+1
<kcoyle> +1
<Dimitris> +1
<Labra> +1
<hsolbrig> +1
<pano> +1
<ericP> +1
RESOLUTION: Open ISSUE-190, ISSUE-191
action-43
<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..
issue-131
<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
+0.5
<marqh> 0
RESOLUTION: Close ISSUE-131, removing sh:hasShape
<TallTed> +1
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
<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?
http://w3c.github.io/data-shapes/shacl/#PartitionConstraintComponent
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
<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
<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