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:08:02 <hsolbrig> scribe: hsolbrig
18:08:18 <TallTed> present+
18:09:20 <kcoyle> we were getting noice from labra - can you mute?
<hsolbrig> topic: Admin
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
<hsolbrig> topic: Disposal of Raised issues
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> topic: 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> topic: 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> topic: 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> topic: 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> topic: 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, ericP
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