IRC log of shapes on 2016-11-16

Timestamps are in UTC.

12:56:12 [RRSAgent]
RRSAgent has joined #shapes
12:56:12 [RRSAgent]
logging to http://www.w3.org/2016/11/16-shapes-irc
12:56:14 [trackbot]
RRSAgent, make logs rdf-data-shapes
12:56:14 [Zakim]
Zakim has joined #shapes
12:56:16 [trackbot]
Zakim, this will be SHAPES
12:56:16 [Zakim]
ok, trackbot
12:56:17 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
12:56:17 [trackbot]
Date: 16 November 2016
12:57:38 [hknublau]
hknublau has joined #shapes
13:02:03 [Arnaud]
present+
13:02:20 [Arnaud]
agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.11.16
13:02:24 [Arnaud]
chair: Arnaud
13:02:44 [hknublau]
present+
13:09:07 [Dimitris]
Dimitris has joined #shapes
13:09:49 [TallTed]
TallTed has joined #shapes
13:13:41 [simonstey]
present+
13:13:48 [Dimitris]
present+
13:14:13 [TallTed]
present+
13:14:54 [hknublau]
scribenick: hknublau
13:18:40 [hknublau]
We should try to look at some of the big tickets in this meeting.
13:18:43 [Arnaud]
PROPOSED: Approve minutes of the 9 Nov 2016 Telecon: http://www.w3.org/2016/11/09-shapes-minutes.html
13:19:23 [simonstey]
+1
13:19:28 [Arnaud]
RESOLVED: Approve minutes of the 9 Nov 2016 Telecon: http://www.w3.org/2016/11/09-shapes-minutes.html
13:19:46 [hknublau]
Arnaud: Next week regular meeting again.
13:20:18 [hknublau]
... depending on progress today, we should schedule more longer meetings in the coming weeks
13:20:28 [hknublau]
topic: Review of meeting goals
13:21:16 [hknublau]
Arnaud: CR status is the big goal; test suite; user-friendly syntax
13:23:00 [hknublau]
topic: Getting to CR
13:23:21 [hknublau]
Arnaud: Next publication could be CR, although this sounds bold
13:23:34 [hknublau]
... Key is to claim we have closed all our issues and had wide review.
13:24:08 [hknublau]
... there should not be a wide delta between previous draft; for this reason we want to republish another draft before CR
13:25:01 [hknublau]
... Test suite is required, because CR is also a call for implementations
13:25:28 [hknublau]
... We don't need a complete test suite but we do need framework, so that spec can point for test suite
13:25:32 [marqh]
marqh has joined #shapes
13:25:47 [hknublau]
... and tests can evolve over time.
13:26:16 [hknublau]
q+
13:26:21 [Arnaud]
ack hknublau
13:27:38 [hknublau]
... On public comments: since there is no more Last Call it is less clear when we are required to follow a formal response process
13:27:58 [hknublau]
... however, we should do our best to respond
13:28:15 [simonstey]
https://www.w3.org/2015/Process-20150901/#doc-reviews
13:28:46 [hknublau]
... also to document that we do have feedback, although technically there is no requirement to respond to all of them.
13:29:02 [AndyS]
AndyS has joined #shapes
13:30:05 [hknublau]
... of course we don't need to agree on the comments
13:31:00 [AndyS]
present+
13:31:19 [kcoyle]
kcoyle has joined #shapes
13:35:28 [hknublau]
q+
13:36:29 [Arnaud]
ack hknublau
13:36:57 [kcoyle]
present+
13:37:42 [simonstey]
q+
13:37:51 [ericP]
hknublau: how about if we have a way for the WG to check diffs
13:37:53 [Arnaud]
ack simonstey
13:38:08 [ericP]
q+ to propose a little mechanism behind hknublau's proposal
13:38:11 [hknublau]
simonstey: I agree, I think we need such a mechanism.
13:38:14 [Dimitris]
I also agree
13:38:59 [Arnaud]
ack ericP
13:38:59 [Zakim]
ericP, you wanted to propose a little mechanism behind hknublau's proposal
13:39:10 [hknublau]
... so that we close public email threads that ask for WG support.
13:39:45 [hknublau]
ericP: The editors could also provide pointers to the most interesting changes.
13:39:48 [hknublau]
+q
13:39:59 [Arnaud]
ack hknublau
13:40:50 [hknublau]
hknublau: everyone should review the changes on a weekly basis
13:41:39 [hknublau]
Arnaud: reasonable to put this on the agenda each week.
13:41:51 [hknublau]
... any disagreements?
13:43:33 [hknublau]
... I want to encourage Karen to raise formal issues on the comments
13:44:01 [hknublau]
kcoyle: I can do that.
13:44:41 [Dimitris]
I can
13:45:52 [hknublau]
ericP: Hint: Ask commenters to prioritize issues
13:46:31 [hknublau]
Arnaud: We are running out of runway, technically until June 1st 2017
13:47:10 [hknublau]
... there is minimum amount of time that we need to grant reviewers and implementers
13:47:31 [hknublau]
... we need to be "done" by end of Feb/March.
13:47:48 [hknublau]
... and holiday season doesn't help.
13:48:28 [hknublau]
... will be very hard to get an extension. If we were in CR and have implementers, we could reasonably ask for extension.
13:48:59 [hknublau]
TOPIC: Test Suite
13:49:49 [hknublau]
Arnaud: We have the framework from last year, we have ShEx tests that could be converted, and Holger's test suite
13:50:15 [hknublau]
ericP: Status on ShEx tests
13:50:36 [hknublau]
... Updated tests for changes to sh:datatype
13:51:08 [hknublau]
... Big issue, converting from ShEx to SHACL. Depends on partition topic.
13:51:27 [hknublau]
... and we requested changes to stem.
13:52:27 [hknublau]
... We don't have target-based tests, use parameters directly.
13:53:50 [simonstey]
q+
13:56:18 [hknublau]
hknublau: we do have a test format, which is integrated with TopBraid, but let's just continue with the format that we defined next year.
13:56:34 [Arnaud]
ack simonstey
13:56:40 [hknublau]
Arnaud: Initially "anyone" can add tests and later they will be stabilized and approved.
13:56:42 [ericP]
q+ to say that in SPARQL, folks would upload contradictory tests and the WG would mark one (hopefully) "approved"
13:56:45 [simonstey]
https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Nov/0039.html
13:58:56 [Arnaud]
ack ericP
13:58:56 [Zakim]
ericP, you wanted to say that in SPARQL, folks would upload contradictory tests and the WG would mark one (hopefully) "approved"
13:59:23 [hknublau]
ericP: In SPARQL WG, people submitted contradicting tests to clarify semantics.
14:00:32 [simonstey]
+1
14:00:40 [Dimitris]
+1
14:00:48 [hknublau]
hknublau: Old tests should be discarded, but we keep the format
14:01:24 [hknublau]
Arnaud: Which format to use?
14:01:59 [hknublau]
ericP: We have manifest files, Holger's format doesn't use/need them.
14:02:22 [hknublau]
... manifest provides metadata such as what kind of test we have
14:02:30 [hknublau]
q+
14:02:49 [Arnaud]
ack hknublau
14:04:01 [hknublau]
... manifest may be compatible with what we have in ShEx
14:04:35 [hknublau]
hknublau: TQ's format can also represent metadata, but I don't want to start controversies on the details of the format.
14:05:37 [hknublau]
Arnaud: Eric should stabilize the test format and then have Eric and Holger to contribute their (converted) tests.
14:05:49 [ericP]
ACTION: ericP to review test suite and compare with shex tesst suite
14:05:50 [trackbot]
Created ACTION-47 - Review test suite and compare with shex tesst suite [on Eric Prud'hommeaux - due 2016-11-23].
14:06:41 [kcoyle]
scribenick: kcoyle
14:07:17 [kcoyle]
Arnaud: TOPIC: User-friendly syntax
14:07:48 [kcoyle]
... background: would possibly use ShEx as basis for compact user-friendly syntax
14:08:10 [kcoyle]
... partitions key to alignment of shex and shacl
14:09:41 [kcoyle]
ericP: Yes, alignment is possible & a good idea
14:10:16 [kcoyle]
... looking at where "or" allowed in shacl
14:10:34 [kcoyle]
... Jose is working on translate from shex to shacl; this means there is a test suite for the two
14:10:56 [ericP]
-> https://shexspec.github.io/spec/ shex spec
14:11:00 [hknublau]
q+
14:11:19 [kcoyle]
... would like to publish shex spec as FPWD, get it out there for review
14:11:54 [kcoyle]
Arnaud: Technically there is a version as a starting point, but was not an editor's draft
14:12:15 [kcoyle]
... so should be offered to group to review
14:12:22 [Arnaud]
ack hknublau
14:13:10 [kcoyle]
hknublau: eric described features needed for shacl to create compatibility; but shex needs to cover all aspects of shacl core
14:13:38 [kcoyle]
Arnaud: may not have a mandate to cover all aspects
14:14:32 [kcoyle]
ericP: shex says that targets are separate from shex;
14:15:01 [kcoyle]
... not clear if target* of shacl is needed
14:15:50 [kcoyle]
... thre is a feature in shex that allows you to have unique keys, e.g. for literal with only one language code
14:16:29 [kcoyle]
... suggest publish was exists, then add to make compatible
14:18:15 [Dimitris]
q+
14:18:15 [kcoyle]
Arnaud: proposal is to make shex a working draft
14:18:29 [Arnaud]
PROPOSED: accept ShEx as an Editor's draft
14:18:33 [Arnaud]
ack Dimitris
14:19:10 [kcoyle]
Dimitris: making it a draft is a good idea; but have to align them or it will be difficult for users, esp. conjunction/disjunction
14:19:29 [hknublau]
hknublau has joined #shapes
14:19:45 [kcoyle]
Arnaud: yes, probably need to add a section explaining the document
14:20:08 [kcoyle]
Dimitris: what is there must be consistent, even if some features are missing
14:20:58 [kcoyle]
ericP: and, or, unary are all the same; n-ary target constraints and repeated groups will need to be translated well
14:21:29 [kcoyle]
Arnaud: alignment will either extend shacl or reduce compact syntax
14:21:42 [kcoyle]
+1
14:21:42 [simonstey]
+1
14:21:46 [ericP]
+1
14:21:47 [Dimitris]
+1
14:21:48 [TallTed]
+1
14:22:45 [Arnaud]
PROPOSED: accept ShEx as an Editor's draft
14:23:29 [kcoyle]
hknublau: this is compact syntax, not shex itself?
14:23:36 [ericP]
-> https://shexspec.github.io/spec/ ShEx Spec
14:24:54 [ericP]
q+
14:25:09 [Arnaud]
ack ericP
14:25:12 [kcoyle]
hknublau: publishing this draft would just be confusing
14:25:27 [hknublau]
-1
14:25:44 [kcoyle]
ericP: shex exists and is being used in practice
14:25:57 [TallTed]
q+
14:26:08 [kcoyle]
... will we uncloak within this group, or separately?
14:26:19 [Arnaud]
ack TallTed
14:26:54 [kcoyle]
TallTed: this is a not uncommon kind of end-run that you (eric) have done before
14:27:42 [kcoyle]
... inappropriate to make this w3c without going through process
14:28:16 [kcoyle]
... should follow how json-ld was brought in; more work needs to be done
14:28:30 [ericP]
q+
14:29:30 [kcoyle]
Arnaud: it's not like we haven't known about shex all along; maybe should have been brought sooner
14:29:57 [ericP]
q-
14:29:57 [kcoyle]
... not sure what the 'right process' is - put it in realm of working group and give the group a chance to work on it
14:30:54 [kcoyle]
TallTed: this is not being presented as: this is for your consideration; my understanding is that shex does not fit
14:31:11 [kcoyle]
... not in the charter
14:31:41 [kcoyle]
Arnaud: Holger says there is too much in this document, so what should be removed?
14:32:21 [kcoyle]
... process is that spec needs to be brought into working group as an editor's draft
14:33:13 [hknublau]
q+
14:33:59 [kcoyle]
ericP: we tried to do this within the group
14:34:33 [kcoyle]
Arnaud: it would be a shame if shex were standardized outside of w3c; we were trying to accommodate both views
14:35:22 [Arnaud]
ack hknublau
14:35:24 [kcoyle]
... analogous to relax ng within xml - so now there are both, which isn't a bad thing, but w3c lost having the relax ng spec
14:36:03 [kcoyle]
hknublau: We decided 1.5 yrs ago that we are not using shex. all we need to do is describe a compact syntax
14:36:35 [kcoyle]
ericP: should shex go someplace else?
14:36:37 [kcoyle]
hknublau: yes
14:37:13 [kcoyle]
Arnaud: This is not making shex a competitor to shacl;
14:37:54 [kcoyle]
TallTed: in the context of this working group, there is nothing in here that references shacl - so how do they align? or are they separate?
14:38:10 [ericP]
-> https://w3c.github.io/data-shapes/shacl-abstract-syntax/shex-to-shacl ShEx-to-SHACL
14:38:34 [kcoyle]
Arnaud: that is the work that needs to take place; the abstract syntax (kcoyle and ericp) and the shex to shacl
14:39:15 [kcoyle]
... we don't want the two to be in isolation from each other; now they are separate and shex is not visible as a wg product
14:39:53 [kcoyle]
... this mainly format/style. note that we have worked to align them, e.g. with partition
14:39:57 [marqh]
q+
14:40:04 [Arnaud]
ack marqh
14:40:26 [kcoyle]
marqh: question: is it a fair comment that shex is a partial implementation?
14:40:58 [kcoyle]
ericP: there is a large intersection; if we put in partition then shex is a nearly complete intersection with shacl
14:41:12 [kcoyle]
... the big difference is the extension mechanism
14:41:28 [kcoyle]
... also stems in value sets
14:42:18 [kcoyle]
marqh: if wg is developing standard for shapes, is it reasonable to publish a relationship between shex and shacl, with shacl being the standard?
14:42:33 [kcoyle]
ericP: i... think.... so.... um
14:42:44 [hknublau]
q+
14:42:46 [kcoyle]
... if the semantics are all captured in ... nope, unsure
14:43:22 [kcoyle]
Arnaud: my mental model is the other way around; you can implement shacl with shex
14:43:42 [kcoyle]
... done through abstract syntax
14:44:09 [kcoyle]
... what matters is if mapping works
14:44:39 [Arnaud]
ack hknublau
14:44:43 [kcoyle]
... if we don't want the layering, then it isn't clear what we're doing
14:45:16 [kcoyle]
hknublau: if shex is an implementation of shacl, (but not vice versa) - then all we need is the compact syntax
14:46:26 [pano]
pano has joined #shapes
14:46:28 [kcoyle]
TallTed: with that flavoring, if shex can be described as an alternative - as a different user-friendly language
14:47:01 [kcoyle]
... but with shacl as the primary point, then that allays many of my fears
14:47:09 [kcoyle]
... right now it looks too independent
14:47:40 [kcoyle]
q+
14:48:47 [kcoyle]
ericP: shacl has evolved a lot; it began as a set of spin-like rules. It has become more of an 'how things work' document
14:49:15 [kcoyle]
... shex has a lot to offer to shacl
14:49:43 [Arnaud]
ack kcoyle
14:50:16 [ericP]
kcoyle: i've not seen a side-by-side comparison of ShEx and SHACL.
14:50:47 [ericP]
... without seeing that, i don't know whether ShEx is a human-friendly representation of SHACL
14:51:03 [ericP]
... until we see that, it's hard to have a real opinion
14:51:27 [ericP]
... could we be presented with something that shows how it interacts with SHACL
14:51:50 [kcoyle]
Arnaud: with sympathy for eric - we can't ask him to do too much
14:51:56 [AndyS]
AndyS has left #shapes
14:52:33 [kcoyle]
... leave it at this for today and give people a chance to look at documentation
14:53:59 [kcoyle]
... eric to send message to group
14:54:19 [kcoyle]
***break for 5***
15:01:55 [Labra]
Labra has joined #shapes
15:03:45 [kcoyle]
back
15:04:47 [Dimitris]
scribenick: Dimitris
15:05:26 [Dimitris]
topic: disposal of raised issues
15:07:24 [Arnaud]
PROPOSED: open ISSUE-195 and ISSUE-196
15:07:25 [Dimitris]
hknublau: (about issue 195) is just to update rdfs:comments, maybe even drop them and keep only labels
15:07:28 [hknublau]
+1
15:07:31 [ericP]
+1
15:07:32 [Dimitris]
+1
15:07:32 [simonstey]
+1
15:07:39 [kcoyle]
+1
15:07:42 [pano]
+1
15:07:56 [Arnaud]
RESOLVED: open ISSUE-195 and ISSUE-196
15:07:58 [TallTed]
+1
15:08:03 [Labra]
+1
15:08:21 [simonstey]
issue-196
15:08:21 [trackbot]
issue-196 -- Should we delete filter shapes? -- open
15:08:21 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/196
15:08:37 [Dimitris]
topic: ISSUE-196
15:09:16 [Dimitris]
Arnaud: there is a very concrete proposal from Holger to delete filter shapes, let's discuss this idea now
15:09:49 [Dimitris]
... that would indeed simplify the model after all the discussions we had
15:10:17 [hknublau]
q+
15:10:25 [Dimitris]
... does any other wants or uses filter shapes or have problems with dropping them?
15:10:27 [ericP]
+q to dropping filter shapes
15:10:29 [Arnaud]
ack hknublau
15:10:33 [ericP]
+1 to dropping filter shapes
15:10:34 [ericP]
q-
15:11:19 [Dimitris]
hknublau: filters are just syntactic sugar for an OR / NOT, it is only a convenience feature but a very expensive one
15:12:54 [Dimitris]
+1 from me as well
15:13:20 [Dimitris]
arnaud: what is sh:disabled?
15:14:29 [Dimitris]
hknublau: it disables some shapes. It can be for reusing other shapes but disabling / deactivating some constraints
15:15:32 [Dimitris]
... means that all focus nodes will be valid
15:15:52 [simonstey]
+q
15:15:57 [kcoyle]
q+
15:16:05 [Arnaud]
ack simonstey
15:17:17 [Dimitris]
simonstey: currently, how would removing filter shapes change the language?
15:18:27 [Dimitris]
hknublau: currently you cannot deactivate a constraint
15:19:01 [TallTed]
q+
15:19:35 [Dimitris]
simonstey: not sure if this should be part of SHACL or implementation specific
15:19:44 [Dimitris]
hknublau: not interoperable
15:19:58 [Arnaud]
ack kcoyle
15:20:35 [Dimitris]
q+
15:21:32 [Dimitris]
kcoyle: spec does not specify processing to say how one can turn things off
15:22:43 [Dimitris]
hknublau: we define what validation is, I only propose a minor change
15:23:35 [Dimitris]
kcoyle: I am lacking the motivation for that feature
15:23:37 [Arnaud]
ack TallTed
15:24:24 [hknublau]
+q to say that you can achieve this via a custom target
15:24:51 [Dimitris]
tallted: does not see a motivation for eliminating filters
15:26:44 [simonstey]
+q
15:27:12 [Arnaud]
ack Dimitris
15:28:12 [Dimitris]
Dimitris: filters are useful but we are out of time
15:28:12 [Arnaud]
ack hknublau
15:28:12 [Zakim]
hknublau, you wanted to say that you can achieve this via a custom target
15:28:30 [Dimitris]
... sh:ignore can be useful for testing shapes
15:28:32 [simonstey]
q-
15:29:18 [Dimitris]
hknublau: custom targets are far more efficient for selecting specific nodes
15:29:34 [hknublau]
straw poll?
15:30:05 [Arnaud]
STRAWPOLL: Delete filter shape and instead, add a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored.
15:30:15 [hknublau]
+1
15:30:23 [Dimitris]
+1
15:30:39 [Labra]
+1 for deleting filter shape, 0 for the boolean flag
15:30:41 [kcoyle]
ted, the graphic has been removed
15:31:04 [kcoyle]
+1 delete filter, 0 for flag
15:31:37 [Arnaud]
PROPOSED: Close ISSUE-196, deleting filter shape and instead, adding a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored (i.e., any node is considered conforming/valid).
15:31:47 [Dimitris]
simonstey: we need to define how sh:ignored is defined in referenced shapes (sh:shape, sh:or, ...)
15:32:01 [hknublau]
+1
15:32:04 [TallTed]
+0.7
15:32:07 [pano]
+1
15:32:10 [Dimitris]
+1
15:32:28 [kcoyle]
+.5
15:32:30 [simonstey]
+0.5
15:32:50 [Labra]
0
15:32:57 [ericP]
+1 filter, 0 for flag
15:33:29 [Labra]
my 0 was for the flag..., +1 for deleting filterShape
15:33:49 [Arnaud]
RESOLVED: Close ISSUE-196, deleting filter shape and instead, adding a boolean flag sh:disabled which (if true) means that a shape or constraint is ignored (i.e., any node is considered conforming/valid).
15:34:12 [simonstey]
issue-185
15:34:12 [trackbot]
issue-185 -- Processing order for filters and constraints -- open
15:34:12 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/185
15:34:16 [simonstey]
issue-192
15:34:16 [trackbot]
issue-192 -- Should filter shapes be of type sh:Shape? if not, then what? -- open
15:34:16 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/192
15:34:30 [Arnaud]
PROPOSED: Close ISSUE-185 and ISSUE-192 as now irrelevant
15:34:38 [simonstey]
+1
15:34:39 [Dimitris]
+1
15:34:48 [hknublau]
+1
15:34:53 [TallTed]
+1
15:35:06 [ericP]
+1
15:35:37 [Labra]
+1
15:35:39 [kcoyle]
+1
15:35:43 [Arnaud]
RESOLVED: Close ISSUE-185 and ISSUE-192 as now irrelevant
15:35:58 [simonstey]
issue-92
15:35:58 [trackbot]
issue-92 -- Should repeated properties be interpreted as additive or conjunctive? -- open
15:35:58 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/92
15:36:15 [Dimitris]
topic: issue-92
16:07:31 [hknublau]
Makes little sense to discuss now, and the proposal is incomplete
16:07:31 [Dimitris]
arnaud: based on the previous discussion let's see what's the status here
16:07:31 [Dimitris]
... Arthur started this and Eric continue working on this
16:07:31 [Dimitris]
eric: I am working on the partition proposal, no updates yet
16:07:31 [Dimitris]
s/eric/ericP/
16:07:31 [Dimitris]
... will nee to see about different ORs in the spec
16:07:31 [Dimitris]
topic: issue-180