See also: IRC log
<kcoyle> doesn't for me - says too early to log on
<TallTed> Webex thinks the call is tomorrow...
<Arnaud> yes, hold on a minute
<Arnaud> eric is working on it
<kcoyle> webex works now
<Arnaud> yes, you may need to refresh the page to get access
<Arnaud> sorry, struggling with audio (again)
<marqh> similarly i do too, I am still updating my calendar to free this space regularly
<marqh> ... * pano I have to leave at 10:00 AM eastern time
<hsolbrig> I have to leave at about 9:55 eastern time due to another meeting as well
<Arnaud> PROPOSED: Approve minutes of the 21 Sept 2016 Telecon: http://www.w3.org/2016/09/21-shapes-minutes.html
<pano> Scribe:pano
RESOLUTION: Approve minutes of the 21 Sept 2016 Telecon: http://www.w3.org/2016/09/21-shapes-minutes.html
subtopic: next meetings
pano: I can't guarantee being there on Tuesdays
<marqh> alternation of day makes attendance more challenging, i'd prefer not to
<Arnaud> PROPOSED: despite the challenges it represents for Pano to attend, we will have our calls on Tuesday
pano: we can do Tuesdays and I'll try to make it as much as possible
<marqh> +1
<ericP> +1
<simonstey> 0 (don't care)
<kcoyle> 0
RESOLUTION: despite the challenges it represents for Pano to attend, we will have our calls on Tuesday
Arnaud: if Jose doesn't call in regularly we will change it back to Wednesday
<Labra> I am starting my connection
<Labra> I had another meeting just before this one
Arnaud: As we try to get to CR it will be a problem if there are public comments that are left unsatisfied.
... we have to keep track of all the comments and the handling and reacting of these to get of CR, and if there are unaddressed comments we will have to issue a new CR
hsolbrig: With respects to the Peter's comment on precision of the spec, the precision is extremely important and I applaud his push for this.
Arnaud: there's one issue that Holger raised, which helps in tackling comments.
<Arnaud> PROPOSED: Open ISSUE-179
<simonstey> +1
<hknublau> +1
<TallTed> +1
<kcoyle> +1
<Labra> +1
+1
<hsolbrig> +1
RESOLUTION: Open ISSUE-179
<Arnaud> PROPOSED: Close ISSUE-163, as addressed
Arnaud: There was a message from Holger saying he believes this can be closed now
<hknublau> +1
<simonstey> issue-163
<trackbot> issue-163 -- should "constraining" and other forms of "constraint" be used less in the specification -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/163
<kcoyle> +1
<hsolbrig> +0
<simonstey> +1
<TallTed> +1
+1
<ericP> +0
<marqh> +1
<Labra> +1
RESOLUTION: Close ISSUE-163, as addressed
<Arnaud> PROPOSAL: Close ISSUE-106 as addressed by this change: https://github.com/w3c/data-shapes/compare/da0f0fbdc4...8e8401ab9d
Arnaud: again, Holger indicated that this issue has been resolved
<simonstey> +1
<hknublau> +1
<kcoyle> +0
<TallTed> +1
+1
<Labra> 0
<hsolbrig> +0
<ericP> 0
RESOLUTION: Close ISSUE-106 as addressed by this change: https://github.com/w3c/data-shapes/compare/da0f0fbdc4...8e8401ab9d
<Arnaud> PROPOSED: Close ISSUE-107 leaving annotation properties as currently specified
<simonstey> issue-107
<trackbot> issue-107 -- annotations and arguments use different mechanisms for specifying the SPARQL variable name -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/107
<hknublau> +1
Arnaud: there was some discussion on this one
<kcoyle> +0
<TallTed> +0
<hsolbrig> +0
+0
<simonstey> 0
<Labra> 0
<Zakim> ericP, you wanted to ask if errors are an annotation
ericP: it seems like errors messages are annotations, in the sense that they dont have semantic impact. Am I right here?
<ericP> 0
RESOLUTION: Close ISSUE-107 leaving annotation properties as currently specified
hknublau: Yes, they are. They are a very small part though, and I don't see a problem.
<Arnaud> PROPOSED: Close ISSUE-142 as addressed by the Terminology section and its use throughout the document.
Arnaud: Peter has expressed concerns about closing this issue.
<hknublau> +1
<hsolbrig> +q
ericP: this issue isn't a very helpful one
<simonstey> +1
<hsolbrig> +1
hsolbrig: I agree. There are some loose terminology issues in the spec, but there should be clear issues for these.
marqh: there are some worthwile parts in this issue that could be seperated out as separate issues that can be discussed more productively
... I'm happy to try and do that in the coming week
kcoyle: It is difficult to explain that something is unclear. One of the useful things we could do is do a group read through of the spec, talking about and working through parts that are unclear.
... It would be nice to have that as a discussion.
Arnaud:
RESOLUTION: Close ISSUE-142 as addressed by the Terminology section and its use throughout the document, separate issues should be raised against specific terminology issues
<kcoyle> +1
<hsolbrig> +1
<hsolbrig> Apologies - have to leave for a 10:00 meeitng. Thnx
+1
scribe: That's interesting idea. I can only propose dicussing these on email currently.
<ericP> +1
<Arnaud> ACTION: marqh to take a read through the spec and raise specific terminology issues as needed [recorded in http://www.w3.org/2016/09/27-shapes-minutes.html#action01]
<trackbot> Created ACTION-43 - Take a read through the spec and raise specific terminology issues as needed [on Mark Hedley - due 2016-10-04].
<Labra> scribe: labra
<Arnaud> 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
<Arnaud> PROPOSED: Close ISSUE-140 as addressed by https://github.com/w3c/data-shapes/commit/2046305962be7cd47400e7a2b51cd2841dca398c
TallTed: It's extremely vague
... every implementation can handle it differently
Holger: Do people agree that we need to support this?
... maybe it is an optional feature and we don't need to support this
... we have already defined for a node what it is to be validated
... it is similar to the hasShape function
<Zakim> ericP, you wanted to say there's some value to APIs
Eric: XML Schema gives a couple of ways on how to associate a document with a schema
... it is a well go to go
... here is a node in a graph and a shape in a schema and check if it matches
... the most important thing is to say this is how we validate a node in a graph...instead of using selectors
Arnaud: Do you agree with Ted?
Eric: Yes, in the abstract syntax and semantics the examples define shapes and instance data except in the section about selectors
Holger: The input basically is a data graph and a shapes graph
Eric: in the examples in the abstract syntax and semantics the notion of validation take a node in a graph and a shape in a schema
... it is very simple to follow that
Holger: But the difference is that we don't know the shape, only the node
EricP: validation is a function that takes a shape in a schema and a node in agraph, then the exampels can be formulated in top of that
Holger: We have already defined what it means for a node to be validated in a shapes graph...it looks for all the shapes
Ted: It seems that we are realizing that there are three inputs, a graph, a shapes graph and a node
Arnaud: there is not going to be a consensus on this at this point
Holger: this should be something that implementations can define one way or another
<trackbot> issue-155 -- problems in the description of property pair constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/155
<Arnaud> PROPOSED: Close ISSUE-155 as handled by the current draft.
<hknublau> +1
<simonstey> +.5
<ericP> http://w3c.github.io/data-shapes/shacl-abstract-syntax/#Comparisonwithcompareproperty defines a semantics for arbitrary numbers of triples
In that example you can see that there are lots of permutations that we cover
kcoyle: I would need an explanation from Holger about why Peter's comments are valid or don't need to be addressed
<simonstey> this issue was raised back in april
kcoyle: Holger says I don't see it as a problem...can you explain that?
Holger: the issue has been raised in april and there has been a lot of work that has solved these issues
... the person who raised this issue is no longer in the WG and nobody else is complaining
Arnaud: Peter didn't complain after taking a look at the agenda also, but we don't know
... if nobody is going to champion the issue, maybe we can just close it optimistically
... and we can reopen it later
<kcoyle> +.5
<ericP> 0
<TallTed> +0
0
<simonstey> I would argue that at least some parts of the issue were already addressed
<simonstey> e.g., we dont have inversepropconstraints anymore
<simonstey> +1
RESOLUTION: Close ISSUE-155 as handled by the current draft
Arnaud: There is some work translating from ShEx testsuite to SHACL
Labra: I am working on it...and I expect to have it in the next 3 weeks or so
... one problem is that there are differences in the semantics and also differences in the way that the processors are being called
... but I am working on it
<trackbot> issue-111 -- How should the working group address the issues called out in the WG charter? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/111
KCoyle: it sounds to me that what he proposes makes sense
... I could try to message this into a fuller introduction for the spec
Holger: I appreciate it and if other people answer in the mailing list
... any input is appreciated
KCoyle: I will do it in an email
<Arnaud> trackbot, end meeting
<TallTed> :-/