IRC log of shapes on 2016-04-14

Timestamps are in UTC.

17:57:34 [RRSAgent]
RRSAgent has joined #shapes
17:57:34 [RRSAgent]
logging to http://www.w3.org/2016/04/14-shapes-irc
17:57:36 [trackbot]
RRSAgent, make logs rdf-data-shapes
17:57:36 [Zakim]
Zakim has joined #shapes
17:57:38 [trackbot]
Zakim, this will be SHAPES
17:57:38 [Zakim]
ok, trackbot
17:57:39 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
17:57:39 [trackbot]
Date: 14 April 2016
17:57:56 [Arnaud]
agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.04.14
17:57:59 [Arnaud]
chair: Arnaud
17:59:36 [Arnaud]
present+
17:59:45 [Dimitris]
Dimitris has joined #shapes
17:59:49 [kcoyle]
present+
18:00:29 [simonstey]
present+
18:01:39 [Labra]
Labra has joined #shapes
18:02:08 [pfps]
pfps has joined #shapes
18:02:09 [hknublau]
hknublau has joined #shapes
18:02:19 [hknublau]
present+
18:02:26 [pfps]
present+
18:02:57 [Dimitris]
present+
18:04:02 [jamsden]
jamsden has joined #shapes
18:04:54 [hsolbrig]
hsolbrig has joined #shapes
18:06:06 [Labra]
present+
18:06:12 [TallTed]
TallTed has joined #shapes
18:07:11 [hsolbrig]
present+
18:07:46 [hsolbrig]
scribnic hsolbrig
18:08:02 [hsolbrig]
scribnic: hsolbrig
18:08:08 [simonstey]
scribe: hsolbrig
18:08:18 [TallTed]
present+
18:09:20 [kcoyle]
we were getting noice from labra - can you mute?
18:09:22 [Arnaud]
PROPOSED: Approve minutes of the 7 April 2016 Telecon: http://www.w3.org/2016/04/07-shapes-minutes.html
18:09:46 [Arnaud]
RESOLVED: Approve minutes of the 7 April 2016 Telecon: http://www.w3.org/2016/04/07-shapes-minutes.html
18:10:23 [hsolbrig]
arnaud: will still consider a longer call in the near future
18:10:41 [pfps]
q+
18:11:14 [Arnaud]
ack pfps
18:11:23 [hsolbrig]
arnaud: are the issues addressed
18:11:38 [hsolbrig]
pfps: 143 appears to be addressed...
18:12:01 [hsolbrig]
... 144 - not adequate to say pre-binding in one place or substitution in the other, cannot verify it is done
18:12:34 [hsolbrig]
... 146 code and text are still not the same - code still propigates through as errors
18:12:42 [hsolbrig]
... 145 and 147 are ok
18:12:43 [Arnaud]
PROPOSED: Close ISSUE-143, ISSUE-145, ISSUE-147, open ISSUE-144, ISSUE-146
18:12:51 [hknublau]
+1
18:12:51 [hsolbrig]
+1
18:12:51 [simonstey]
+1
18:12:56 [Dimitris]
+1
18:13:02 [kcoyle]
+1
18:13:41 [hsolbrig]
pfps: It would be really nice if someone else would review the spec. Errors aren't being caught.
18:13:45 [Arnaud]
RESOLVED: Close ISSUE-143, ISSUE-145, ISSUE-147, open ISSUE-144, ISSUE-146
18:14:38 [jamsden]
q+
18:14:52 [Arnaud]
ack jamsden
18:14:52 [hsolbrig]
arnaud: at least two people need to take an action/commitment to review spec
18:15:54 [hsolbrig]
jamsden: I read the spec, but not sure what I would read next time around. Proposal 3 and 4 are outstanding and we don't know what to review.
18:16:12 [pfps]
for example, noticing that pre-binding is used in some places and substitution in others doesn't require a deep technical competence
18:16:38 [hsolbrig]
arnaud: Issue 95 is on the agenda (which involves proposal 3) and maybe that will get proposal 4 closer
18:16:45 [simonstey]
issue-78
18:16:45 [trackbot]
issue-78 -- Should SHACL support marking classes as abstract -- open
18:16:45 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/78
18:18:04 [hknublau]
q+
18:18:56 [hsolbrig]
jamsden: wrote up a possible use case, tried to address Holger's concerns. I think we're getting close to something that could be adopted or accepted...
18:19:02 [Arnaud]
ack hknublau
18:20:13 [hsolbrig]
hknublau: trying to come up with an intuitive definition. As soon as you have a bridge between shapes and classes, conditions for abstract become very hard.
18:20:29 [hsolbrig]
+q
18:20:34 [Arnaud]
ack hsolbrig
18:21:21 [jamsden]
q+
18:21:23 [Arnaud]
hsolbrig: the problem is that abstract it would have to be connected with type rather than shape
18:21:32 [Arnaud]
ack jamsden
18:21:49 [hsolbrig]
jamsden: it is intended to be a constraint on instances.
18:22:06 [hsolbrig]
q+
18:22:11 [Arnaud]
ack hsolbrig
18:22:49 [Arnaud]
hsolbrig: proposal in the issue description is linked to rdf:type
18:23:03 [hsolbrig]
jamsden: rdf:type is an artifact of the test.
18:23:05 [Dimitris]
q+
18:23:12 [Arnaud]
ack Dimitris
18:23:39 [Arnaud]
Dimitris's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0099.html
18:23:41 [hsolbrig]
dimitris: my proposal for abstract is something that has a type but no data.
18:24:17 [hsolbrig]
jamsden: class entails having data that is shared with subclass
18:25:00 [hsolbrig]
arnaud: We could close it and re-open if a definition shows up or just leave it open
18:25:41 [hsolbrig]
jamsden: There is a proposal in the email, but hasn't been submitted yet.
18:26:23 [hsolbrig]
issue-95
18:26:23 [trackbot]
issue-95 -- Proposed simplification and clean up of template mechanism -- open
18:26:23 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/95
18:27:27 [hsolbrig]
arnaud: for the sake of allowing progress to be made, could we accept proposal 3 and close issue 95? It provides improvements over what is in the spec today
18:27:48 [hsolbrig]
arnaud: and would give us a new reference point that captures the group's current thinking
18:28:30 [Arnaud]
PROPOSED: Close ISSUE-95, adopting Proposal 3 https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
18:28:35 [hsolbrig]
arnaud: we had a straw poll that gave Peter's proposal some time and that is still on the table
18:28:36 [simonstey]
+1
18:28:38 [Dimitris]
+1
18:28:39 [pfps]
q+
18:28:43 [jamsden]
+1
18:28:45 [Arnaud]
ack pfps
18:28:50 [hknublau]
+1
18:29:27 [hsolbrig]
pfps: If arnaud's words "take root" then I'm for it. But if the group sticks with "we can't change anything" then ...
18:30:03 [TallTed]
+1
18:30:15 [hsolbrig]
arnaud: we have to allow for changes to be made if the group concludes this the right thing to do. Nothing is cast in stone at this point.
18:30:29 [hsolbrig]
+1
18:31:43 [Labra]
0
18:31:45 [pfps]
0 - this is an advance but I'm not seeing it as a way towards a good spec
18:31:49 [kcoyle]
+.5
18:32:05 [jamsden]
q+
18:32:11 [Arnaud]
ack jamsden
18:32:22 [kcoyle]
I share some of Peter's concerns
18:32:48 [TallTed]
q+
18:33:05 [hsolbrig]
jmasden: we're not making any progress in the current approach. Selecting one of the other will provide us with a spec that is reviewable. Does not preclude same approach with proposal 4
18:34:16 [Arnaud]
ack TallTed
18:35:47 [hsolbrig]
TallTed: We are making progress. They may feel small, but they are steps. It is how the game is payed. A wholesale rewrite requires a saleseman that can show that it solves what we've already solved
18:35:50 [Arnaud]
RESOLVED: Close ISSUE-95, adopting Proposal 3 https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
18:36:57 [hsolbrig]
TallTed: if there are fundamental issues that must be solved, we should do them now.
18:38:45 [hknublau]
q+
18:39:03 [hsolbrig]
arnaud: lets tone it down and be polite on the mailing list. Everyone wants this to work
18:40:37 [Arnaud]
ack hknublau
18:43:03 [hsolbrig]
issue-135
18:43:03 [trackbot]
issue-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open
18:43:03 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/135
18:43:53 [hsolbrig]
arnaud: Holger proposed syntactic sugar to allow and/or/not directly
18:44:09 [pfps]
q+
18:44:23 [Arnaud]
ack pfps
18:45:16 [hsolbrig]
pfps: Proposal as written doesn't work because it views them as constraints...
18:45:34 [hsolbrig]
... we have a complicated mechanism for determining what to do with constraints and this doesn't fit.
18:45:37 [hknublau]
q+
18:46:03 [simonstey]
q+
18:46:49 [Arnaud]
ack hknublau
18:46:50 [hsolbrig]
arnaud: Proposal 4 gets rid of the notion of constraint. This proposal goes toward this, but for a specific case.
18:46:56 [simonstey]
-q
18:47:10 [jamsden]
jamsden has joined #shapes
18:47:39 [jamsden]
q+
18:47:54 [hsolbrig]
hknublau: Implementation strategy would be that has shape function would take two different arguments -- default predicate and ? It can be implemented.
18:48:23 [hsolbrig]
hknublau: Current syntax can become quite overwhelming.
18:48:59 [Arnaud]
ack jamsden
18:49:06 [hsolbrig]
hknublau: I could make this a bit more formal. The most difficult bit is determining whether the node is a shape or a constraint.
18:49:25 [hsolbrig]
jamsden: Could we view these constraints in the context of an anonymous shape?
18:50:17 [hsolbrig]
arnaud: Holger will look at beefing up proposal and we can look at it again.
18:50:30 [hsolbrig]
issue-138
18:50:30 [trackbot]
issue-138 -- Should property constraints use rdf:Lists? -- open
18:50:30 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/138
18:51:28 [hsolbrig]
arnaud: Proposal 4 uses lists a lot more than the current spec.
18:52:21 [hknublau]
q+
18:52:26 [Arnaud]
ack hknublau
18:53:16 [hsolbrig]
hknublau: Most data models use name/value pairs. Instead of using a list with name as first property, defining it as a first position in a list is a show-stopper for me.
18:53:31 [simonstey]
lists would allow for repeated constraints, i.e., (sh:label [sh:minCount 1] [sh:minCount 2]) right?
18:53:37 [hsolbrig]
hknublau: properties have other values like a name or restriction
18:53:44 [pfps]
q+
18:53:45 [simonstey]
nvm
18:53:49 [Arnaud]
ack pfps
18:54:16 [hknublau]
@simonstey, multiple properties will already be supported (there is a proposal to allow that)
18:54:46 [hsolbrig]
pfps: The only reason to pull the predicate property out of the larger object is to allow it not be in the way to making shapes and constraints the same. I don't see any reason to do this in the current setup
18:55:08 [simonstey]
yep, noticed it.. hence the "nvm" ;)
18:55:10 [ericP]
q+ to say that ShEx use cases reuse value expressions across multiple properties in multiple shapes
18:55:17 [hsolbrig]
pfps: It could be a good idea in other setups
18:55:19 [Arnaud]
ack ericP
18:55:19 [Zakim]
ericP, you wanted to say that ShEx use cases reuse value expressions across multiple properties in multiple shapes
18:55:39 [Arnaud]
STRAWPOLL: should we use rdf:Lists for property constraints as suggested by peter in his proposal 4?
18:55:51 [Dimitris]
q+
18:56:14 [hsolbrig]
ericP: ShEx reuses the same properties in different shapes.
18:56:36 [Dimitris]
http://docs.scala-lang.org/tutorials/tour/named-parameters.html
18:56:39 [Arnaud]
ack Dimitris
18:56:57 [hknublau]
@ericP this is similar to sh:valueShape or we could add sh:shape for node constraints
18:56:58 [hsolbrig]
ericP: In an RDF representation, would be nice not to have to do it, so maybe a shorthand aproach to stand off
18:57:20 [ericP]
hknublau, ack
18:57:26 [hknublau]
-1
18:57:39 [hsolbrig]
arnaud: Straw poll -- should we switch to using lists
18:58:12 [hsolbrig]
ericp: are we a language where everything is ordered, nothing or ordered or a mix?
18:58:26 [hsolbrig]
hknublau: lists of and / or
18:58:31 [kcoyle]
0
18:58:34 [pfps]
I agree that it is nice to be able to have a clean division between the property part of a constraint and the other bits of the constraint. However, this is currently possible by making a shape and reusing that. Of course then you get into the problem that this may bulk up the size of the language.
18:58:35 [pfps]
0
18:58:36 [jamsden]
0
18:58:37 [ericP]
prefer lists to mixed
18:58:40 [hsolbrig]
0
18:58:49 [Labra]
+0.5
18:58:50 [Dimitris]
-0.5
18:59:01 [ericP]
so +0.5
18:59:12 [simonstey]
-0.5
18:59:12 [TallTed]
-0.5
18:59:15 [pfps]
me I'll scribe should i 'nick?
18:59:24 [pfps]
scribe: pfps
18:59:50 [pfps]
0 - there is no particular advantage to moving to lists in the current syntax
18:59:57 [simonstey]
not sure about its benefits/implications
19:00:09 [pfps]
arnaud: this looks mostly negative so I suggest that we close this
19:00:51 [Arnaud]
PROPOSED: Close ISSUE-138, saying no, we won't use rdf:Lists for property constraints
19:00:56 [hknublau]
+1
19:00:58 [pfps]
arnaud: hopefully this will reduce the differences between the different proposals
19:00:59 [pfps]
0
19:01:03 [jamsden]
+1
19:01:04 [Dimitris]
+1
19:01:05 [simonstey]
+1
19:01:14 [ericP]
0
19:01:20 [kcoyle]
+1
19:01:30 [hknublau]
The SPARQL on lists is horrible.
19:01:34 [Labra]
0
19:01:35 [TallTed]
+0
19:01:59 [Arnaud]
RESOLVED: Close ISSUE-138, saying no, we won't use rdf:Lists for property
19:02:30 [pfps]
ISSUE-133
19:02:30 [trackbot]
ISSUE-133 -- syntax simplification and regularization -- open
19:02:30 [trackbot]
http://www.w3.org/2014/data-shapes/track/issues/133
19:03:29 [Arnaud]
https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-133:_syntax
19:03:29 [hknublau]
q+
19:03:29 [pfps]
arnaud: this is the crux of the difference between two proposals
19:03:35 [Arnaud]
ack hknublau
19:03:42 [pfps]
q+
19:03:59 [pfps]
holger: i noticed that the restriction to have a single value is unnecessary
19:04:23 [pfps]
holger: this wasn't supported in SPIN but there is no real reason to support it, particularly for single-parameter constraints
19:05:43 [Arnaud]
ack pfps
19:05:44 [pfps]
ISSUE-133 is mostly about not separating constraints and shapes but the topics on the proposal page are two minor syntax changes
19:07:21 [simonstey]
+1
19:07:27 [simonstey]
(to 1c)
19:07:29 [pfps]
arnaud: it appears that there are some advances that can be made on the proposals page
19:08:12 [pfps]
pfps: I'm in favour of something that is not listed
19:08:41 [pfps]
pfps: the problem with 1b is the combinatorial approach
19:08:54 [pfps]
pfps: I'm OK with 1c
19:09:45 [pfps]
pfps: as written 1c is vacuous in property and inverse property constraints because all components are multi-parameters
19:10:33 [pfps]
holger: I don't count sh:predicate as an argument
19:11:03 [Dimitris]
PROPOSED: it is legal to have constraint components appear multiple times within the same constraint for all single argument constraints (excluding sh:predicate)
19:11:26 [pfps]
pfps: the group needs to be clear as to what is gong on
19:11:31 [hknublau]
+1
19:11:51 [pfps]
+0.5 - this is OK
19:11:56 [Dimitris]
+1
19:11:57 [TallTed]
+1
19:12:05 [simonstey]
+1
19:12:16 [kcoyle]
+12
19:12:27 [jamsden]
+1
19:12:31 [Labra]
+1
19:12:50 [Arnaud]
RESOLVED: it is legal to have constraint components appear multiple times within the same constraint for all single argument constraints (excluding sh:predicate)
19:13:35 [pfps]
arnaud: we can either look at topic 2 or go to merging shapes and constraints
19:13:49 [pfps]
arnaud: topic 2 for issue-133 on the proposal page
19:14:19 [simonstey]
q+
19:14:32 [pfps]
holger: there are a couple of examples in the core that use two arguments but this is mostly for extensions
19:15:07 [pfps]
holger: if there is only a single parameter then components can be tied to the name of that single parameter
19:15:26 [Arnaud]
ack simonstey
19:15:50 [pfps]
holger: multi-parameter components then need to use a complex object which I don't view as user friendly
19:16:21 [pfps]
simon: having multi-parameter components makes it hard to see what needs to be combined
19:16:46 [pfps]
simon: on the other hand constraint templates need more than one argument
19:16:47 [pfps]
q+
19:17:31 [Arnaud]
ack pfps
19:19:00 [pfps]
pfps: templates can just get access to properties of a complex values even if you don't have property paths
19:19:23 [pfps]
pfps: as far as sh:closed goes, it seems to me that it would be better as a single-argument component
19:20:03 [hknublau]
See also Items 14+ on https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html
19:20:24 [pfps]
pfps: sh:closed takes a list of ignored properties
19:20:30 [Dimitris]
+q
19:20:34 [Arnaud]
ack Dimitris
19:20:52 [kcoyle]
i didn't follow it, but do not like "implicit" constraints.
19:21:09 [pfps]
dimitris: i'm more inclined to the multi-argument view as we already have sh:predicate as an implicit argument
19:21:17 [pfps]
q+
19:21:21 [Arnaud]
ack pfps
19:22:01 [hknublau]
q+
19:22:13 [pfps]
pfps: actually the status of sh:predicate is even a bit unclear - to some extent its a "switch" which picks out different implementations
19:22:27 [Arnaud]
ack hknublau
19:23:00 [pfps]
holger: I put a list of other problems that I found with this
19:23:11 [pfps]
q+
19:23:36 [pfps]
holger: you can already group multi-argument components into their own constraint node
19:23:47 [pfps]
q-
19:24:09 [pfps]
arnaud: what do we do about this topic?
19:24:44 [pfps]
eric: holger said that we can always create a separate constraint for multi-argument components
19:24:57 [pfps]
holger: yes
19:25:19 [pfps]
eric: if I had two patterns with two flags I would just create two constraints
19:25:46 [pfps]
eric: you can shove as many things into the constraint as long as you don't get a repeated property
19:26:21 [pfps]
eric: if you had a pattern flag that was "g" and one that was "i" that would be a repeated property and that would need to be put accross multiple constraints
19:26:52 [pfps]
holger: that would be illegal as it would be a multi-argument component parameter showing up more than once
19:27:21 [pfps]
eric: can there be a bad association even without a repeated property
19:27:22 [pfps]
q+
19:27:43 [pfps]
holger: I don't think so, in the core
19:27:52 [pfps]
holger: that doesn't help for extensions
19:28:28 [pfps]
eric: each component goes into its own constraint but there is a shorthand for the common case
19:28:33 [Arnaud]
ack pfps
19:28:37 [pfps]
q-
19:29:28 [pfps]
pfps: the core's current design means that there is no interference except for repeated multi-argument component parameters, but extensions could destroy this characteristic
19:30:24 [hknublau]
Could we try to close this?
19:30:49 [pfps]
arnaud: I encourage more discussion on the mailing list
19:31:40 [Arnaud]
trackbot, end meeting
19:31:40 [trackbot]
Zakim, list attendees
19:31:40 [Zakim]
As of this point the attendees have been Arnaud, kcoyle, simonstey, hknublau, pfps, Dimitris, Labra, hsolbrig, TallTed, .5
19:31:48 [trackbot]
RRSAgent, please draft minutes
19:31:48 [RRSAgent]
I have made the request to generate http://www.w3.org/2016/04/14-shapes-minutes.html trackbot
19:31:49 [trackbot]
RRSAgent, bye
19:31:49 [RRSAgent]
I see no action items