IRC log of shapes on 2016-07-07

Timestamps are in UTC.

18:00:54 [RRSAgent]
RRSAgent has joined #shapes
18:00:54 [RRSAgent]
logging to
18:00:56 [trackbot]
RRSAgent, make logs rdf-data-shapes
18:00:56 [Zakim]
Zakim has joined #shapes
18:00:58 [trackbot]
Zakim, this will be SHAPES
18:00:58 [Zakim]
ok, trackbot
18:00:59 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
18:00:59 [trackbot]
Date: 07 July 2016
18:01:32 [jamsden]
jamsden has joined #shapes
18:02:22 [Arnaud]
chair: Arnaud
18:02:32 [Arnaud]
18:03:29 [Arnaud]
18:03:43 [hknublau]
hknublau has joined #shapes
18:03:52 [simonstey]
18:04:13 [AndyS]
18:04:13 [kcoyle]
18:04:20 [jamsden]
18:04:51 [hknublau]
18:05:32 [TallTed]
18:05:39 [pano]
18:08:27 [AndyS]
FYI -- Progress on pre-bind/EXISTS: Peter's summary of problems to look at:
18:09:46 [Dimitris]
18:11:15 [Arnaud]
PROPOSED: Approve minutes of the 30 June 2016 Telecon:
18:12:11 [hsolbrig]
hsolbrig has joined #shapes
18:12:16 [hsolbrig]
present+ hsolbrig
18:12:21 [hsolbrig]
scribenick hsolbrig
18:12:22 [Arnaud]
RESOLVED: Approve minutes of the 30 June 2016 Telecon:
18:13:13 [hsolbrig]
arnaud: Eric - you have an open action.
18:14:16 [hsolbrig]
issue 132
18:14:23 [Arnaud]
18:14:23 [trackbot]
issue-132 -- sh:predicate is used in many constraints but not always available -- open
18:14:23 [trackbot]
18:14:52 [hknublau]
18:14:54 [Dimitris]
18:14:57 [hsolbrig]
ericP: I'm not sure how this goes away...
18:15:07 [Arnaud]
ack hknublau
18:15:14 [Dimitris]
18:16:01 [hsolbrig]
hknublau: the wording was referring to propertyConstraint...
18:16:17 [hsolbrig]
eric: sparql definitions still look at predicate?
18:16:43 [hsolbrig]
hknublau: no there is no predicate anymore, just ask queries.
18:16:52 [hsolbrig]
eric: When was that changed?
18:17:00 [hsolbrig]
hknublau: this week.
18:17:24 [Arnaud]
PROPOSED: Close ISSUE-132 as no longer relevant, sh:predicate is no longer used in the latest editor's draft
18:18:06 [hsolbrig]
hknublau: ?predicate has disappeared except in definition of sh:closed.
18:18:09 [Arnaud]
PROPOSED: Close ISSUE-132 as no longer relevant, ?predicate is no longer used in the latest editor's draft
18:18:16 [hknublau]
18:18:17 [ericP]
18:18:17 [hsolbrig]
18:18:23 [simonstey]
18:18:28 [Dimitris]
18:18:30 [kcoyle]
18:18:30 [TallTed]
18:18:46 [Arnaud]
RESOLVED: Close ISSUE-132 as no longer relevant, ?predicate is no longer used in the latest editor's draft
18:19:01 [hsolbrig]
18:19:01 [trackbot]
issue-41 -- Using property paths to refer to values/types? -- open
18:19:01 [trackbot]
18:20:18 [hsolbrig]
ericP: worth noting that support was not overwhelming in discussion.
18:20:50 [hsolbrig]
arnaud: how much more time do we need?
18:21:15 [ericP]
just above <>
18:22:57 [Arnaud]
PROPOSED: Close ISSUE-41, based on previous resolution and latest editor's draft
18:23:03 [simonstey]
18:23:03 [hknublau]
18:23:04 [ericP]
18:23:05 [hsolbrig]
18:23:06 [jamsden]
18:23:12 [Dimitris]
18:23:28 [TallTed]
18:23:31 [kcoyle]
18:23:54 [Arnaud]
RESOLVED: Close ISSUE-41, based on previous resolution and latest editor's draft
18:24:07 [simonstey]
18:24:07 [trackbot]
issue-65 -- Consistency and cohesiveness of nomenclature (e.g., shapes, scopes, and constraints) -- open
18:24:07 [trackbot]
18:24:39 [hsolbrig]
arnaud: we spent quite a bit of time on the terminology in the document. Spec has been reworked with help from Dimitris and Karen...
18:24:58 [hsolbrig]
... it doesn't prevent anybody from bringing up specifics later on.
18:25:07 [Arnaud]
PROPOSED: Close ISSUE-65, no longer relevant given all the changes made to the draft
18:25:11 [jamsden]
18:25:14 [hknublau]
18:25:14 [Dimitris]
18:25:17 [hsolbrig]
18:25:19 [simonstey]
18:25:23 [TallTed]
18:25:24 [kcoyle]
18:25:32 [ericP]
18:25:42 [Arnaud]
RESOLVED: Close ISSUE-65, no longer relevant given all the changes made to the draft
18:26:00 [hsolbrig]
18:26:00 [trackbot]
issue-166 -- separate out advanced part of specification -- open
18:26:00 [trackbot]
18:26:23 [hsolbrig]
arnaud: relates to discussion about how many documents we should have...
18:26:44 [hsolbrig]
... several members proposed split, TopQuadrant was resisting ...
18:26:58 [kcoyle]
18:27:21 [hsolbrig]
... on mailer, external party (Tom Baker) said why not split?
18:27:41 [jamsden]
18:27:43 [Arnaud]
ack kcoyle
18:28:30 [hsolbrig]
kcoyle: Holger's email indicated that there are dependencies, so they aren't entirely separable. Would be better looking at after language were solidified...
18:28:51 [hsolbrig]
... prefer keeping it open and coming back at the end.
18:28:54 [Arnaud]
ack jamsden
18:29:33 [hsolbrig]
jamsden: went through editing work for 7 part OSLC. Multi-parts add editing overhead, but I like decoupling and separation of concerns.
18:30:02 [hsolbrig]
... separation might be useful. Right now benefit might be low compared to cost
18:31:01 [hsolbrig]
AndyS: split that is too much on the expert side. If core and extension mechanisms reflect clear difference...
18:32:14 [hsolbrig]
arnaud: from audience view, makes sense. From editorial perspective, helps identify dependencies so it might be a useful exercise
18:33:06 [hsolbrig]
arnaud: don't hear a push to split, but happy to leave issue open for the time being
18:33:24 [jamsden]
18:33:35 [Arnaud]
ack jamsden
18:34:07 [hsolbrig]
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.
18:34:27 [hsolbrig]
... recommend doing or not doing, but not delaying any longer.
18:35:54 [hsolbrig]
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...
18:36:27 [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
18:36:40 [hsolbrig]
... SPARQL queries in section 4 have references to advanced sections and include pre-bindings. Had included it, but it led to duplication
18:37:01 [TallTed]
(personally, I see no need for this split.)
18:37:52 [hsolbrig]
Dimitris: agree with Holger. Prefer one document, but if we split it would prefer at the end vs. now
18:38:11 [hknublau]
I think the split would be less relevant if we had a Primer.
18:39:11 [hsolbrig]
arnaud: not certain that Primer will ever happen. Time is short
18:39:19 [Arnaud]
PROPOSED: Close ISSUE-166, keeping the spec as one document
18:39:29 [hknublau]
18:39:36 [jamsden]
18:39:39 [simonstey]
18:39:40 [Dimitris]
18:39:41 [hsolbrig]
18:39:41 [TallTed]
18:39:42 [kcoyle]
18:39:42 [AndyS]
18:39:49 [ericP]
18:40:11 [Arnaud]
RESOLVED: Close ISSUE-166, keeping the spec as one document
18:40:29 [hsolbrig]
18:40:29 [trackbot]
issue-52 -- Define an Abstract Syntax for SHACL -- open
18:40:29 [trackbot]
18:41:13 [hsolbrig]
arnaud: Eric submitted an abstract syntax for the core, meant to help bridge ShEx/SHACL gaps
18:41:19 [jamsden]
18:41:22 [hsolbrig]
... what do people think?
18:41:31 [Arnaud]
ack jamsden
18:42:32 [hsolbrig]
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.
18:42:50 [hsolbrig]
... don't think it needs to be normative. Is there a non-normative work product that can be published?
18:42:53 [hknublau]
18:43:25 [hsolbrig]
arnaud: Yes - can be published as non-normative.
18:43:56 [hsolbrig]
ericP: Wanted a way to bridge ShEx syntax like SPARQL has a grammar and abstract syntax and semantics against abstract syntax.
18:43:59 [kcoyle]
18:44:44 [hsolbrig]
ericP: a few people found it a quick read to help understand SHACL. Benefits to people who are familiar with abstract syntax...
18:45:14 [hsolbrig]
arnaud: publish on its own -- working group note? Non-normative appendix?
18:45:41 [Arnaud]
ack kcoyle
18:46:09 [hsolbrig]
kcoyle: Does this formalism actually express everything that is in SHACL.
18:46:34 [hsolbrig]
ericp: covered SHACL core except hasShape recursiveness until last week. Path expressions have changed
18:46:51 [jamsden]
18:46:57 [hsolbrig]
kcoyle: Could it be exactly parallel to SHACL core?
18:47:02 [hsolbrig]
EricP: yes
18:47:11 [hsolbrig]
kcoyle: Extension mechanism?
18:47:52 [hsolbrig]
EricP: more complicated. Core is not that complex -- fairly simple rule-based process...
18:48:24 [hsolbrig]
... rule for SHACL extensions is more abstract. Have to turn into SPARQL, construct SPARQL query, etc.
18:49:08 [hsolbrig]
kcoyle: Since we've said extension doesn't have to be SHACL, I'm confused. Is it defined in a way that uses other technologies?
18:49:43 [hsolbrig]
EricP: SHACL core could be implemented using Python/rdflib for example...
18:50:29 [hsolbrig]
... 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.
18:51:03 [hsolbrig]
kcoyle: Tells me that core should not be dependent on SPARQL, so abstract syntax would be suitable to describe core.
18:51:25 [TallTed]
s/extension doesn't have to be SHACL/extension doesn't have to be SPARQL/
18:52:21 [hsolbrig]
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.
18:52:23 [jamsden]
18:52:28 [Arnaud]
ack jamsden
18:53:20 [hsolbrig]
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?...
18:53:29 [hknublau]
18:54:12 [hsolbrig]
... (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?
18:54:23 [ericP]
18:54:36 [hsolbrig]
... note that questions don't apply to non-normative.
18:55:23 [hsolbrig]
arnaud: the "if this is wrong" is only as a last resort. It is done in many specs.
18:55:37 [Arnaud]
ack hknublau
18:56:16 [hsolbrig]
hnkublau: open to having this as a separate document. Role overlaps with textual definitions that we already have....
18:56:53 [Arnaud]
ack ericP
18:56:54 [hsolbrig]
... SPARQL gives executable definition, and we get SPARQL testing for free.
18:57:54 [hsolbrig]
ericP: verification of syntax is fairly trivial in a language such as Scala. Pretty easy to do machine verification.
18:58:04 [hsolbrig]
arnaud: Has Iovka looked at this?
18:58:12 [hsolbrig]
EricP: Yes - she liked it
18:58:31 [AndyS]
18:58:40 [Arnaud]
ack AndyS
18:58:50 [hsolbrig]
q+ to say I have to leave and someone needs to scribe.
19:00:50 [hknublau]
scribenick: hknublau
19:01:22 [kcoyle]
19:01:29 [Arnaud]
ack hsolbrig
19:01:29 [Zakim]
hsolbrig, you wanted to say I have to leave and someone needs to scribe.
19:01:31 [hknublau]
AndyS: There is a cost of keeping normative definitions in synch
19:01:51 [hknublau]
... in SPARQL the Algebra is normative
19:01:56 [Arnaud]
ack kcoyle
19:02:27 [hknublau]
kcoyle: In DCMI community we had problems with $ variables and binding
19:03:06 [hknublau]
... Would using an Abstract Syntax reduce the need for the SPARQL?
19:03:15 [hknublau]
EricP: Yes IHMO
19:04:48 [Dimitris]
19:05:01 [hknublau]
AndyS: We would have to try. Abstract Syntax would become yet another language.
19:05:50 [hknublau]
Arnaud: We had long discussions on this topic in the early days of the WG. Some people were suggesting an Abstract Syntax then already.
19:06:16 [hknublau]
... ISSUE-52 was opened as a compromise to accommodate that view point.
19:07:30 [hknublau]
... We have a resolution to use SPARQL "as much as possible".
19:07:38 [Arnaud]
ack Dimitris
19:08:08 [hknublau]
Dimitris: Replacing SPARQL with another language would not solve Karen's problem
19:08:15 [hknublau]
... One option would be to hide SPARQL by default
19:08:32 [simonstey]
19:08:47 [Arnaud]
ack simonstey
19:08:54 [hknublau]
Arnaud: Or have Abstract Syntax as an optional view
19:09:38 [hknublau]
simonstey: Abstract Syntax would have made more sense in the beginning, and we could have used SPARQL as one example
19:09:51 [hknublau]
... but changing everything now (at this stage) may not be the best way forward
19:10:30 [hknublau]
Arnaud: The same old positions are resurfacing. Jose is not even present.
19:11:30 [hknublau]
... at least agreement that we should publish this informally, but I see no agreement on more
19:12:48 [hknublau]
EricP: Yes I can prepare it as an Appendix working draft.
19:14:34 [Arnaud]
PROPOSED: Put Eric's proposed abstract syntax into a Working Draft (Editor's draft)
19:15:06 [ericP]
19:15:06 [simonstey]
19:15:09 [jamsden]
19:15:09 [hknublau]
19:15:13 [TallTed]
19:15:15 [kcoyle]
19:15:22 [AndyS]
+1 to at least publish as a note/informative/other -- ideally with evaluation semantics as well
19:15:29 [Dimitris]
19:15:49 [Arnaud]
RESOLVED: Put Eric's proposed abstract syntax into a Working Draft (Editor's draft)
19:17:02 [hknublau]
Arnaud: Should we close the ticket now?
19:17:10 [Arnaud]
RESOLVED: Close ISSUE-52, put Eric's proposed abstract syntax into a Working Draft (Editor's draft)
19:17:47 [hknublau]
19:17:47 [trackbot]
issue-139 -- Can all constraint properties be applied in all scenarios? -- open
19:17:47 [trackbot]
19:18:20 [hknublau]
Arnaud: What is left to decide here?
19:19:36 [simonstey]
19:19:48 [kcoyle]
time for another editpr
19:19:56 [ericP]
19:19:57 [kcoyle]
editor's draft?
19:20:03 [Dimitris]
19:20:04 [ericP]
19:20:04 [Arnaud]
ack ericP
19:20:13 [hknublau]
From my perspective the language is good now.
19:20:51 [hknublau]
ericP: The table is still there
19:21:29 [hknublau]
... the language would be slightly more expressive if we allowed everything everywhere/
19:21:47 [hknublau]
... like in ShEx
19:22:35 [Arnaud]
ack Dimitris
19:23:24 [hknublau]
Dimitris: Two questions: a) can they all apply everywhere b) how to implement this, e.g. using the extension mechanism
19:23:32 [hknublau]
19:24:20 [Arnaud]
ack hknublau
19:24:25 [hknublau]
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]
19:25:28 [ericP]
19:29:23 [hknublau]
hknublau: Discussion based on the pirate pad
19:30:02 [hknublau]
... I don't think there is value in allowing every constraint component everywhere, because many components do not make sense as property/node constraints
19:30:29 [hknublau]
ericP: Kind of agreement
19:30:39 [kcoyle]
Holger, can you put that also in an email? thx
19:30:59 [TallTed]
19:31:10 [hknublau]
Dimitris: Agree in principle, issue with error reporting
19:31:12 [Arnaud]
ack TallTed
19:31:32 [hknublau]
TellTed: Question is who are we making life simpler for, and how much simpler does it become?
19:31:54 [hknublau]
Arnaud: People have different view points
19:32:34 [Arnaud]
trackbot, end meeting
19:32:34 [trackbot]
Zakim, list attendees
19:32:34 [Zakim]
As of this point the attendees have been Arnaud, simonstey, AndyS, kcoyle, jamsden, hknublau, TallTed, pano, Dimitris, hsolbrig, .6
19:32:42 [trackbot]
RRSAgent, please draft minutes
19:32:42 [RRSAgent]
I have made the request to generate trackbot
19:32:43 [trackbot]
RRSAgent, bye
19:32:43 [RRSAgent]
I see no action items