RDF Data Shapes Working Group Teleconference

14 Jul 2016


See also: IRC log


Dimitris, Arnaud, kcoyle, marqh, AndyS, TallTed, pano, hsolbrig, hknublau, ericP, jamsden


<scribe> scribenick: pano

<marqh> pano: https://www.w3.org/2009/CommonScribe/manual.html


<Arnaud> PROPOSED: Approve minutes of the 7 July 2016 Telecon: http://www.w3.org/2016/07/07-shapes-minutes.html

RESOLUTION: Approve minutes of the 7 July 2016 Telecon: http://www.w3.org/2016/07/07-shapes-minutes.html

Disposal of Raised Issues

Arnaud: not sure this issue is purely editorial

<Arnaud> issue-174

<trackbot> issue-174 -- Scopenode does not use RDF node definition -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/174

Karen: I think most of this has been dealt with. I may put in some small editorial issues.

Arnaud: Do we agree that there is an issue?

Karen: For me it was a question.

Dimitris: I don't think there is an issue. the terms property and predicate are used interchangeably in the spec, which causes confusion.
... Maybe Karen has a suggestion on how to fix this editorial issue

Karen: Thinking about it
... I still have a question about the sparlq part. What is the outcome of the sparql for sh:scopeNode?

Dimitris: Sparql is a graph pattern matching language. bind binds $this which is a specific node as a focus node.

<Zakim> ericP, you wanted to say that we're basically using sh:scopeNode as an invocation API; e.g. once we know the list of nodes that we want to validate as some shape, we can generate a

Karen: I think it is unclear and needs to be explained more clearly

ericP: what will happen if you got a shape with multiple scopes on it it will intersect the scope nodes with the subjects and objects in the graph
... it's filtered against the subjects and objects in the graph

in the graph*

Arnaud: We were trying to close the issue, and Karen and Dimitris were going to raise the necessary editorial issues

Karen: Yes I will add this to the editorial issue I'm working on.


Arnaud: Let's discuss Holger's Email

SHACL Core Syntax Issues

Holger: There were 3 proposals
... its an open question of whether node constraint and shape can be merged
... one of the reasons for leaving it is consistency with the current spec, and this is how we started and it is right now.

<Zakim> ericP, you wanted to say that an AND or OR may also contain node constraints

ericp: AND and OR may also contain node constraints

<ericP> ericP: i think we should test it with OR use cases and make sure that it doesn't render anything ambiguous or require too much context for the reader to be able to understand a constraint

jamsden: a simpler higher level view of this: we're trying to put constraints of graphs, so the idea of shapes to me makes sense.

Arnaud: I think the argument of Peter was to make the syntax more universal
... The argument against that from holger is that you allow things that don't make sense

<ericP> i think jamsden is trying to avoid russell's paradox

jamsden: what are the long term consequences of leaving as it is and learning from it
... btw this is what resource shapes already does

Holger: I'm optimistic that this works

Arnaud: How do we solve this?

Dimitris: I agree with Jim
... Does the sh:or works with sh:hasValue, sh:equals
... ?

Holger: if you have a prop contraint that is pointing at an OR and that is pointing at a value, that is not legal.
... the shape points at an OR, and there are two properties in it.

Dimitris: That makes it a bit confusing

Arnaud: Let's try to do a straw poll and see where people stand.

<Arnaud> STRAWPOLL: a) merge sh:NodeConstraint and sh:Shape, b) keep them separate (status quo)

<hknublau> a: +1 b: 0

<kcoyle> a: -1 b: +1

<jamsden> a: 0, b: +5

<TallTed> a: +1 b: 0

<hsolbrig> a: +1 b: 0

<Dimitris> a) -0.1 b) +1

<marqh> a: +1 b:+0.5

jamsden: I'm not sure it matters as much as we think that it's matters

<ericP> a: 0, b:+50

<ericP> a: 0, b:+1

Arnaud: think this means we're staying with b

Karen: It seems to me, that if it's so hard to explain this change, and if it makes the using have to make different decisions in different situations.
... we've only seen one example, and we need more to be convinced.

Arnaud: Shapes being collection of constraints, which Jim mentioned, is an explanation I like.

Holger: we should keep in mind that we started off with some understanding of what a shape is. But if we we're to start now with current knowledge we would probably have a different design

Arnaud: So, Holger will make a proposal with example
... Issue 137 says that the spec doesn't address one of the use cases; for language tags


Karen: things we want to do:
... 1. literal must have a language tag
... 2. literal must have a specific language tag
... 3. no language can be used more than once

Holger: 3 can be covered using uniqueLang

1 is also covered

scribe: so it's only 2
... one could be to do language IN

<trackbot> issue-137 -- Missing constraint for language tag -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/137

scribe: another would be to use a pattern

<AndyS> langMatches(...) in SPARQL

<Arnaud> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0262.html

Karen: I think also complex language codes need to be covered, not just the 2 or 3 letter language codes

Arnaud: Seems like the solutions are not very complicated
... we just need to make a decision on which path to take
... I'm inclined to keep it simple and try to make a proposal which addresses the most basic use cases

Holger: In my email there is an example with langShape. The other option would be to leave it to the extension mechanism

<Dimitris> I would prefer a simple solution and leave complex handling to extension mechanisms

Karen: So that is for the issue 2.
... I was thinking of solving 1. and 3. in the primer

<Dimitris> I am not sure id we have use cases to justify a complex solution like sh:langShape

Arnaud: Do we want to talk about issue-139?

Dimitris: we shouldn't decide on this too late, because it can have impact on the syntax


<trackbot> issue-139 -- Can all constraint properties be applied in all scenarios? -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/139

Arnaud: I think we had a strawpoll and the result was that we wanted to investigate this further

Karen: I would need to have a better idea of what changes in shacl

Dimitris: it will make the spec a little bit simpler
... now we have a table in section 4. If we say that all constraints are applicable everywhere, this removes the need for the table.
... it does mean that some constraints would not makes sense, which should be explained

<Arnaud> http://w3c.github.io/data-shapes/shacl/#h-constraints

<kcoyle> http://w3c.github.io/data-shapes/shacl/#constraints-value-type

Karen: What, if anything, does it do to the contraint components and supporting contexts?

Dimitris: This is a recap of the table, so this would also be removed

Holger: I agree that we could remove some words from the spec, but then we have to add words elsewhere

<hknublau> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Jul/0018.html

If we allow contraints everywhere then a spec implementer should create extra checks

scribe: there is a distinction between set based constraints and node based contraints, which is useful for the user

Arnaud: Eric, what is the ShEx view on this point?

ericP: ShEx has a more generalised model

<hknublau> Much of the generalization was already achieved by merging sh:inverseProperty into sh:path

Arnaud: Do you feel this makes the implementation more complex?

ericP: It makes it less code, but it makes it harder to write that code
... Also, in the more absract model JSON syntax has the shacl like behavior of having shapes with triple constraints the value of which are in turn shapes

<Arnaud> STRAWPOLL: a) make constraint properties applicable in all scenarios, b) no, keep it the way it is

<hknublau> a: -1 b: +1

<kcoyle> a: +1 b:-.8

<jamsden> a: -.5 b: +1

<Dimitris> a) +1 b) -0.5

<AndyS> 0

<ericP> a: 0 b: 0

<TallTed> a: +1 b: +0

Arnaud: Dimitris, can you explain your position

Dimitris: I think it makes things simpler for the spec and for the user
... I don't see why we should complicate the language. If the contraint doesn't make sense, maybe the engine can produce a compiler-like warning

Arnaud: I know Holger's position is that you shouldn't allow a use constraints in places that don't make sense

Holger: And I also haven't yet seen an implementation in sparql with one query

Arnaud: I find it interesting that Dimitris has changes position. I think Dimitris and Holger should continue the discussion
... I feel we need to solve this.
... We're out of time. Please look at Dimitris' proposal on issue-150

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 7 July 2016 Telecon: http://www.w3.org/2016/07/07-shapes-minutes.html
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/07/23 15:58:00 $