See also: IRC log
<hsolbrig> scribe: hsolbrig
<kcoyle> we were getting noice from labra - can you mute?
<Arnaud> PROPOSED: Approve minutes of the 7 April 2016 Telecon: http://www.w3.org/2016/04/07-shapes-minutes.html
RESOLUTION: Approve minutes of the 7 April 2016 Telecon: http://www.w3.org/2016/04/07-shapes-minutes.html
arnaud: will still consider a longer call in the near future
... are the issues addressed
pfps: 143 appears to be addressed...
... 144 - not adequate to say pre-binding in one place or substitution in the other, cannot verify it is done
... 146 code and text are still not the same - code still propigates through as errors
... 145 and 147 are ok
<Arnaud> PROPOSED: Close ISSUE-143, ISSUE-145, ISSUE-147, open ISSUE-144, ISSUE-146
<hknublau> +1
+1
<simonstey> +1
<Dimitris> +1
<kcoyle> +1
pfps: It would be really nice if someone else would review the spec. Errors aren't being caught.
RESOLUTION: Close ISSUE-143, ISSUE-145, ISSUE-147, open ISSUE-144, ISSUE-146
arnaud: at least two people need to take an action/commitment to review spec
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.
<pfps> for example, noticing that pre-binding is used in some places and substitution in others doesn't require a deep technical competence
arnaud: Issue 95 is on the agenda (which involves proposal 3) and maybe that will get proposal 4 closer
<trackbot> issue-78 -- Should SHACL support marking classes as abstract -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/78
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...
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.
+q
<Arnaud> hsolbrig: the problem is that abstract it would have to be connected with type rather than shape
jamsden: it is intended to be a constraint on instances.
<Arnaud> hsolbrig: proposal in the issue description is linked to rdf:type
jamsden: rdf:type is an artifact of the test.
<Arnaud> Dimitris's proposal: https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0099.html
dimitris: my proposal for abstract is something that has a type but no data.
jamsden: class entails having data that is shared with subclass
arnaud: We could close it and re-open if a definition shows up or just leave it open
jamsden: There is a proposal in the email, but hasn't been submitted yet.
<trackbot> issue-95 -- Proposed simplification and clean up of template mechanism -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/95
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
... and would give us a new reference point that captures the group's current thinking
<Arnaud> PROPOSED: Close ISSUE-95, adopting Proposal 3 https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
arnaud: we had a straw poll that gave Peter's proposal some time and that is still on the table
<simonstey> +1
<Dimitris> +1
<jamsden> +1
<hknublau> +1
pfps: If arnaud's words "take root" then I'm for it. But if the group sticks with "we can't change anything" then ...
<TallTed> +1
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.
+1
<Labra> 0
<pfps> 0 - this is an advance but I'm not seeing it as a way towards a good spec
<kcoyle> +.5
<kcoyle> I share some of Peter's concerns
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
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
RESOLUTION: Close ISSUE-95, adopting Proposal 3 https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
TallTed: if there are fundamental issues that must be solved, we should do them now.
arnaud: lets tone it down and be polite on the mailing list. Everyone wants this to work
<trackbot> issue-135 -- Should sh:and/sh:or/sh:not/sh:valueShape support constraints too? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/135
arnaud: Holger proposed syntactic sugar to allow and/or/not directly
pfps: Proposal as written doesn't work because it views them as constraints...
... we have a complicated mechanism for determining what to do with constraints and this doesn't fit.
arnaud: Proposal 4 gets rid of the notion of constraint. This proposal goes toward this, but for a specific case.
<simonstey> -q
hknublau: Implementation strategy would be that has shape function would take two different arguments -- default predicate and ? It can be implemented.
... Current syntax can become quite overwhelming.
... I could make this a bit more formal. The most difficult bit is determining whether the node is a shape or a constraint.
jamsden: Could we view these constraints in the context of an anonymous shape?
arnaud: Holger will look at beefing up proposal and we can look at it again.
<trackbot> issue-138 -- Should property constraints use rdf:Lists? -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/138
arnaud: Proposal 4 uses lists a lot more than the current spec.
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.
<simonstey> lists would allow for repeated constraints, i.e., (sh:label [sh:minCount 1] [sh:minCount 2]) right?
hknublau: properties have other values like a name or restriction
<simonstey> nvm
<hknublau> @simonstey, multiple properties will already be supported (there is a proposal to allow that)
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
<simonstey> yep, noticed it.. hence the "nvm" ;)
pfps: It could be a good idea in other setups
<Zakim> ericP, you wanted to say that ShEx use cases reuse value expressions across multiple properties in multiple shapes
<Arnaud> STRAWPOLL: should we use rdf:Lists for property constraints as suggested by peter in his proposal 4?
ericP: ShEx reuses the same properties in different shapes.
<Dimitris> http://docs.scala-lang.org/tutorials/tour/named-parameters.html
<hknublau> @ericP this is similar to sh:valueShape or we could add sh:shape for node constraints
ericP: In an RDF representation, would be nice not to have to do it, so maybe a shorthand aproach to stand off
<ericP> hknublau, ack
<hknublau> -1
arnaud: Straw poll -- should we switch to using lists
ericp: are we a language where everything is ordered, nothing or ordered or a mix?
hknublau: lists of and / or
<kcoyle> 0
<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.
<pfps> 0
<jamsden> 0
<ericP> prefer lists to mixed
0
<Labra> +0.5
<Dimitris> -0.5
<ericP> so +0.5
<simonstey> -0.5
<TallTed> -0.5
<pfps> me I'll scribe should i 'nick?
<pfps> scribe: pfps
0 - there is no particular advantage to moving to lists in the current syntax
<simonstey> not sure about its benefits/implications
arnaud: this looks mostly negative so I suggest that we close this
<Arnaud> PROPOSED: Close ISSUE-138, saying no, we won't use rdf:Lists for property constraints
<hknublau> +1
arnaud: hopefully this will reduce the differences between the different proposals
0
<jamsden> +1
<Dimitris> +1
<simonstey> +1
<ericP> 0
<kcoyle> +1
<hknublau> The SPARQL on lists is horrible.
<Labra> 0
<TallTed> +0
RESOLUTION: Close ISSUE-138, saying no, we won't use rdf:Lists for property
<trackbot> ISSUE-133 -- syntax simplification and regularization -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/133
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-133:_syntax
arnaud: this is the crux of the difference between two proposals
holger: i noticed that the restriction to have a single value is unnecessary
... this wasn't supported in SPIN but there is no real reason to support it, particularly for single-parameter constraints
ISSUE-133 is mostly about not separating constraints and shapes but the topics on the proposal page are two minor syntax changes
<simonstey> +1
<simonstey> (to 1c)
arnaud: it appears that there are some advances that can be made on the proposals page
pfps: I'm in favour of something that is not listed
... the problem with 1b is the combinatorial approach
... I'm OK with 1c
... as written 1c is vacuous in property and inverse property constraints because all components are multi-parameters
holger: I don't count sh:predicate as an argument
<Dimitris> PROPOSED: it is legal to have constraint components appear multiple times within the same constraint for all single argument constraints (excluding sh:predicate)
pfps: the group needs to be clear as to what is gong on
<hknublau> +1
+0.5 - this is OK
<Dimitris> +1
<TallTed> +1
<simonstey> +1
<kcoyle> +12
<jamsden> +1
<Labra> +1
RESOLUTION: it is legal to have constraint components appear multiple times within the same constraint for all single argument constraints (excluding sh:predicate)
arnaud: we can either look at topic 2 or go to merging shapes and constraints
... topic 2 for issue-133 on the proposal page
holger: there are a couple of examples in the core that use two arguments but this is mostly for extensions
... if there is only a single parameter then components can be tied to the name of that single parameter
... multi-parameter components then need to use a complex object which I don't view as user friendly
simon: having multi-parameter components makes it hard to see what needs to be combined
... on the other hand constraint templates need more than one argument
pfps: templates can just get access to properties of a complex values even if you don't have property paths
... as far as sh:closed goes, it seems to me that it would be better as a single-argument component
<hknublau> See also Items 14+ on https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html
pfps: sh:closed takes a list of ignored properties
<Dimitris> +q
<kcoyle> i didn't follow it, but do not like "implicit" constraints.
dimitris: i'm more inclined to the multi-argument view as we already have sh:predicate as an implicit argument
pfps: actually the status of sh:predicate is even a bit unclear - to some extent its a "switch" which picks out different implementations
holger: I put a list of other problems that I found with this
... you can already group multi-argument components into their own constraint node
arnaud: what do we do about this topic?
eric: holger said that we can always create a separate constraint for multi-argument components
holger: yes
eric: if I had two patterns with two flags I would just create two constraints
... you can shove as many things into the constraint as long as you don't get a repeated property
... 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
holger: that would be illegal as it would be a multi-argument component parameter showing up more than once
eric: can there be a bad association even without a repeated property
holger: I don't think so, in the core
... that doesn't help for extensions
eric: each component goes into its own constraint but there is a shorthand for the common case
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
<hknublau> Could we try to close this?
arnaud: I encourage more discussion on the mailing list
<Arnaud> trackbot, end meeting