See also: IRC log
<AndyS> FYI -- Progress on pre-bind/EXISTS: Peter's summary of problems to look at: https://lists.w3.org/Archives/Public/public-sparql-exists/2016Jul/0020.html
<hsolbrig> scribenick: hsolbrig
<Arnaud> PROPOSED: Approve minutes of the 30 June 2016 Telecon: http://www.w3.org/2016/06/30-shapes-minutes.html
RESOLUTION: Approve minutes of the 30 June 2016 Telecon: http://www.w3.org/2016/06/30-shapes-minutes.html
arnaud: Eric - you have an open action.
<Arnaud> issue-132
<trackbot> issue-132 -- sh:predicate is used in many constraints but not always available -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/132
ericP: I'm not sure how this goes away...
hknublau: the wording was referring to propertyConstraint...
eric: sparql definitions still look at predicate?
hknublau: no there is no predicate anymore, just ask queries.
eric: When was that changed?
hknublau: this week.
<Arnaud> PROPOSED: Close ISSUE-132 as no longer relevant, sh:predicate is no longer used in the latest editor's draft
hknublau: ?predicate has disappeared except in definition of sh:closed.
<Arnaud> PROPOSED: Close ISSUE-132 as no longer relevant, ?predicate is no longer used in the latest editor's draft
<hknublau> +1
<ericP> +1
+1
<simonstey> +1
<Dimitris> +1
<kcoyle> +1
<TallTed> +1
RESOLUTION: Close ISSUE-132 as no longer relevant, ?predicate is no longer used in the latest editor's draft
<trackbot> issue-41 -- Using property paths to refer to values/types? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/41
ericP: worth noting that support was not overwhelming in discussion.
arnaud: how much more time do we need?
<ericP> just above <https://www.w3.org/2016/06/30-shapes-minutes#resolution04>
<Arnaud> PROPOSED: Close ISSUE-41, based on previous resolution and latest editor's draft
<simonstey> +1
<hknublau> +1
<ericP> +0
+1
<jamsden> +1
<Dimitris> +1
<TallTed> +1
<kcoyle> 0
RESOLUTION: Close ISSUE-41, based on previous resolution and latest editor's draft
<trackbot> issue-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/65
arnaud: we spent quite a bit of time on the terminology in the document. Spec has been reworked with help from Dimitris and Karen...
... it doesn't prevent anybody from bringing up specifics later on.
<Arnaud> PROPOSED: Close ISSUE-65, no longer relevant given all the changes made to the draft
<jamsden> +1
<hknublau> +1
<Dimitris> +1
+1
<simonstey> +1
<TallTed> +1
<kcoyle> +1
<ericP> +1
RESOLUTION: Close ISSUE-65, no longer relevant given all the changes made to the draft
<trackbot> issue-166 -- separate out advanced part of specification -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/166
arnaud: relates to discussion about how many documents we should have...
... several members proposed split, TopQuadrant was resisting ...
... on mailer, external party (Tom Baker) said why not split?
kcoyle: Holger's email indicated that there are dependencies, so they aren't entirely separable. Would be better looking at after language were solidified...
... prefer keeping it open and coming back at the end.
jamsden: went through editing work for 7 part OSLC. Multi-parts add editing overhead, but I like decoupling and separation of concerns.
... separation might be useful. Right now benefit might be low compared to cost
AndyS: split that is too much on the expert side. If core and extension mechanisms reflect clear difference...
arnaud: from audience view, makes sense. From editorial perspective, helps identify dependencies so it might be a useful exercise
... don't hear a push to split, but happy to leave issue open for the time being
jamsden: disagree. Really good for editors to know what they are working with. Organization is best done up front and then stuck with. Refactor earlier rather than later.
... recommend doing or not doing, but not delaying any longer.
hknublau: technically it is possible. There are references that go across boundaries. html right now comes from style sheet, would loose that ability with multi documents...
<TallTed> in the split case, the terms section should get replicated ... the headache is making sure that changes to either doc reflect in the other
hknublau: SPARQL queries in section 4 have references to advanced sections and include pre-bindings. Had included it, but it led to duplication
<TallTed> (personally, I see no need for this split.)
Dimitris: agree with Holger. Prefer one document, but if we split it would prefer at the end vs. now
<hknublau> I think the split would be less relevant if we had a Primer.
arnaud: not certain that Primer will ever happen. Time is short
<Arnaud> PROPOSED: Close ISSUE-166, keeping the spec as one document
<hknublau> +1
<jamsden> +.6
<simonstey> +0
<Dimitris> +1
+0
<TallTed> +1
<kcoyle> -.5
<AndyS> +0.5
<ericP> -.5
RESOLUTION: Close ISSUE-166, keeping the spec as one document
<trackbot> issue-52 -- Define an Abstract Syntax for SHACL -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/52
arnaud: Eric submitted an abstract syntax for the core, meant to help bridge ShEx/SHACL gaps
... what do people think?
jamsden: I looked at it and like it. As spec reader it confuses me, as there are multiple syntaxes -- core, ShEx, this and extensibility mechanism.
... don't think it needs to be normative. Is there a non-normative work product that can be published?
<hknublau> +1
arnaud: Yes - can be published as non-normative.
ericP: Wanted a way to bridge ShEx syntax like SPARQL has a grammar and abstract syntax and semantics against abstract syntax.
... a few people found it a quick read to help understand SHACL. Benefits to people who are familiar with abstract syntax...
arnaud: publish on its own -- working group note? Non-normative appendix?
kcoyle: Does this formalism actually express everything that is in SHACL.
ericp: covered SHACL core except hasShape recursiveness until last week. Path expressions have changed
kcoyle: Could it be exactly parallel to SHACL core?
EricP: yes
kcoyle: Extension mechanism?
EricP: more complicated. Core is not that complex -- fairly simple rule-based process...
... rule for SHACL extensions is more abstract. Have to turn into SPARQL, construct SPARQL query, etc.
kcoyle: Since we've said extension doesn't have to be SPARQL, I'm confused. Is it defined in a way that uses other technologies?
EricP: SHACL core could be implemented using Python/rdflib for example...
... in principle, you could implement all the stuff in the SPARQL extension mechanism, but I don't have any idea what a JavaScript extension mechanism(s) would look like.
kcoyle: Tells me that core should not be dependent on SPARQL, so abstract syntax would be suitable to describe core.
arnaud: non-normative? Could be normative and defer to SPARQL if issues or visa-versa. We have to make sure we don't break what exists.
jamsden: Any time you include something in a spec, you need to consider (1) what is its purpose? What does it add? This is a different but redundant approach. Is it necessary?...
... (2) any time you add something, you have to verify that it is correct and support it -- you can't really say "if this is wrong"... what is the intended use?
... note that questions don't apply to non-normative.
arnaud: the "if this is wrong" is only as a last resort. It is done in many specs.
hnkublau: open to having this as a separate document. Role overlaps with textual definitions that we already have....
... SPARQL gives executable definition, and we get SPARQL testing for free.
ericP: verification of syntax is fairly trivial in a language such as Scala. Pretty easy to do machine verification.
arnaud: Has Iovka looked at this?
EricP: Yes - she liked it
<hknublau> scribenick: hknublau
<Zakim> hsolbrig, you wanted to say I have to leave and someone needs to scribe.
AndyS: There is a cost of keeping normative definitions in synch
... in SPARQL the Algebra is normative
kcoyle: In DCMI community we had problems with $ variables and binding
... Would using an Abstract Syntax reduce the need for the SPARQL?
EricP: Yes IHMO
AndyS: We would have to try. Abstract Syntax would become yet another language.
Arnaud: We had long discussions on this topic in the early days of the WG. Some people were suggesting an Abstract Syntax then already.
... ISSUE-52 was opened as a compromise to accommodate that view point.
... We have a resolution to use SPARQL "as much as possible".
Dimitris: Replacing SPARQL with another language would not solve Karen's problem
... One option would be to hide SPARQL by default
<simonstey> +q
Arnaud: Or have Abstract Syntax as an optional view
simonstey: Abstract Syntax would have made more sense in the beginning, and we could have used SPARQL as one example
... but changing everything now (at this stage) may not be the best way forward
Arnaud: The same old positions are resurfacing. Jose is not even present.
... at least agreement that we should publish this informally, but I see no agreement on more
EricP: Yes I can prepare it as an Appendix working draft.
<Arnaud> PROPOSED: Put Eric's proposed abstract syntax into a Working Draft (Editor's draft)
<ericP> +1
<simonstey> +1
<jamsden> +1
0
<TallTed> +1
<kcoyle> +1
<AndyS> +1 to at least publish as a note/informative/other -- ideally with evaluation semantics as well
<Dimitris> +1
Arnaud: Should we close the ticket now?
RESOLUTION: Close ISSUE-52, put Eric's proposed abstract syntax into a Working Draft (Editor's draft)
<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/139
Arnaud: What is left to decide here?
<simonstey> https://www.w3.org/2016/06/30-shapes-minutes.html#item05
<kcoyle> time for another editpr
<kcoyle> editor's draft?
<ericP> http://w3c.github.io/data-shapes/shacl/#h-constraints
From my perspective the language is good now.
ericP: The table is still there
... the language would be slightly more expressive if we allowed everything everywhere/
... like in ShEx
Dimitris: Two questions: a) can they all apply everywhere b) how to implement this, e.g. using the extension mechanism
On Value Nodes "forEach": - sh:and/sh:or/sh:not - sh:class/sh:classIn - sh:datatype/sh:datatypeIn - sh:in - sh:maxInclusive/sh:minExclusive etc - sh:maxLength/sh:minLength - sh:nodeKind - sh:pattern - sh:shape - sh:stem -> Just a single (ASK) validator needed On Property Pairs: - sh:disjoint/sh:equals - sh:lessThan/sh:lessThanOrEquals -> Just a single SELECT validator needed (property constraints) On Sets of Value Nodes: - sh:maxCount/sh:minCount [CUT]
<ericP> http://piratepad.net/Oj8vDGHONz
hknublau: Discussion based on the pirate pad
... I don't think there is value in allowing every constraint component everywhere, because many components do not make sense as property/node constraints
ericP: Kind of agreement
<kcoyle> Holger, can you put that also in an email? thx
Dimitris: Agree in principle, issue with error reporting
TellTed: Question is who are we making life simpler for, and how much simpler does it become?
Arnaud: People have different view points
<Arnaud> trackbot, end meeting