RDF Data Shapes Working Group Teleconference

14 Apr 2016


See also: IRC log


Arnaud, kcoyle, simonstey, hknublau, pfps, Dimitris, Labra, hsolbrig, TallTed, ericP
hsolbrig, pfps


<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

Disposal of Raised issues

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


<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.


<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.


<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


<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


<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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 7 April 2016 Telecon: http://www.w3.org/2016/04/07-shapes-minutes.html
  2. Close ISSUE-143, ISSUE-145, ISSUE-147, open ISSUE-144, ISSUE-146
  3. Close ISSUE-95, adopting Proposal 3 https://www.w3.org/2014/data-shapes/wiki/ISSUE-95:_Metamodel_simplifications#Proposal_3
  4. Close ISSUE-138, saying no, we won't use rdf:Lists for property
  5. it is legal to have constraint components appear multiple times within the same constraint for all single argument constraints (excluding sh:predicate)
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/04/21 23:16:58 $