See also: IRC log
<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
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.
ok
Arnaud: Let's discuss Holger's Email
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