IRC log of shapes on 2016-07-14

Timestamps are in UTC.

17:58:01 [RRSAgent]
RRSAgent has joined #shapes
17:58:01 [RRSAgent]
logging to
17:58:03 [trackbot]
RRSAgent, make logs rdf-data-shapes
17:58:03 [Zakim]
Zakim has joined #shapes
17:58:05 [trackbot]
Zakim, this will be SHAPES
17:58:05 [Zakim]
ok, trackbot
17:58:06 [trackbot]
Meeting: RDF Data Shapes Working Group Teleconference
17:58:06 [trackbot]
Date: 14 July 2016
17:58:25 [Arnaud]
chair: Arnaud
17:58:54 [Arnaud]
17:58:57 [Dimitris]
Dimitris has joined #shapes
17:59:29 [kcoyle]
kcoyle has joined #shapes
17:59:47 [Dimitris]
18:00:00 [Arnaud]
18:00:14 [kcoyle]
18:00:24 [marqh]
18:00:35 [AndyS]
18:00:52 [TallTed]
18:01:04 [pano]
18:03:56 [Arnaud]
present +hknublau
18:04:38 [jamsden]
jamsden has joined #shapes
18:05:06 [hsolbrig]
hsolbrig has joined #shapes
18:05:11 [hsolbrig]
18:05:14 [pano]
scribenick: pano
18:05:15 [hknublau]
18:05:15 [marqh]
18:05:41 [Arnaud]
PROPOSED: Approve minutes of the 7 July 2016 Telecon:
18:06:12 [Arnaud]
RESOLVED: Approve minutes of the 7 July 2016 Telecon:
18:06:29 [Arnaud]
present +jamsden
18:06:37 [Arnaud]
present +ericP
18:07:31 [pano]
Arnaud: not sure this issue is purely editorial
18:08:02 [Arnaud]
18:08:02 [trackbot]
issue-174 -- Scopenode does not use RDF node definition -- raised
18:08:02 [trackbot]
18:08:45 [pano]
Karen: I think most of this has been dealt with. I may put in some small editorial issues.
18:09:04 [pano]
Arnaud: Do we agree that there is an issue?
18:09:13 [Dimitris]
18:09:40 [Arnaud]
ack Dimitris
18:09:42 [pano]
Karen: For me it was a question.
18:11:07 [pano]
Dimitris: I don't think there is an issue. the terms property and predicate are used interchangeably in the spec, which causes confusion.
18:11:29 [pano]
... Maybe Karen has a suggestion on how to fix this editorial issue
18:11:39 [pano]
Karen: Thinking about it
18:12:54 [pano]
... I still have a question about the sparlq part. What is the outcome of the sparql for sh:scopeNode?
18:14:31 [pano]
Dimitris: Sparql is a graph pattern matching language. bind binds $this which is a specific node as a focus node.
18:15:19 [ericP]
q+ 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 shapes graph with multiple sh:scopeNode arcs on that shape, which will return that set of nodes.
18:15:34 [Arnaud]
ack ericP
18:15:34 [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
18:15:37 [Zakim]
... shapes graph with multiple sh:scopeNode arcs on that shape, which will return that set of nodes.
18:15:57 [pano]
Karen: I think it is unclear and needs to be explained more clearly
18:19:20 [pano]
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
18:20:19 [pano]
... it's filtered against the subjects and objects and the graph
18:20:34 [pano]
in the graph*
18:21:14 [ericP]
s/and the graph/in the graph/
18:21:22 [pano]
Arnaud: We were trying to close the issue, and Karen and Dimitris were going to raise the necessary editorial issues
18:22:01 [pano]
Karen: Yes I will add this to the editorial issue I'm working on.
18:22:44 [pano]
18:23:43 [pano]
Arnaud: Let's discuss Holger's Email
18:24:08 [pano]
Holger: There were 3 proposals
18:25:11 [ericP]
q+ to say that an AND or OR may also contain node constraints
18:26:40 [pano]
... its an open question of whether node constraint and shape can be merged
18:28:12 [pano]
... one of the reasons for leaving it is consistency with the current spec, and this is how we started and it is right now.
18:28:17 [Arnaud]
ack ericP
18:28:17 [Zakim]
ericP, you wanted to say that an AND or OR may also contain node constraints
18:32:09 [pano]
ericp: AND and OR may also contain node constraints
18:32:41 [jamsden]
18:36:29 [Dimitris]
18:36:41 [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
18:36:47 [Arnaud]
ack jamsden
18:37:58 [pano]
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.
18:38:44 [pano]
Arnaud: I think the argument of Peter was to make the syntax more universal
18:39:11 [pano]
... The argument against that from holger is that you allow things that don't make sense
18:39:29 [ericP]
i think jamsden is trying to avoid russell's paradox
18:39:31 [pano]
jamsden: what are the long term consequences of leaving as it is and learning from it
18:39:56 [pano]
... btw this is what resource shapes already does
18:40:41 [pano]
Holger: I'm optimistic that this works
18:41:04 [Arnaud]
ack Dimitris
18:41:09 [pano]
Arnaud: How do we solve this?
18:41:22 [pano]
Dimitris: I agree with Jim
18:42:22 [pano]
... Does the sh:or works with sh:hasValue, sh:equals
18:42:56 [pano]
... ?
18:43:35 [pano]
Holger: if you have a prop contraint that is pointing at an OR and that is pointing at a value, that is not legal.
18:45:50 [pano]
... the shape points at an OR, and there are two properties in it.
18:46:08 [pano]
Dimitris: That makes it a bit confusing
18:46:54 [pano]
Arnaud: Let's try to do a straw poll and see where people stand.
18:47:02 [Arnaud]
STRAWPOLL: a) merge sh:NodeConstraint and sh:Shape, b) keep them separate (status quo)
18:47:29 [hknublau]
a: +1 b: 0
18:47:37 [kcoyle]
a: -1 b: +1
18:47:50 [jamsden]
a: 0, b: +5
18:47:56 [TallTed]
a: +1 b: 0
18:47:58 [hsolbrig]
a: +1 b: 0
18:48:00 [Dimitris]
a) -0.1 b) +1
18:48:03 [marqh]
a: +1 b:+0.5
18:48:46 [pano]
jamsden: I'm not sure it matters as much as we think that it's matters
18:48:47 [ericP]
a: 0, b:+50
18:48:59 [ericP]
a: 0, b:+1
18:49:38 [pano]
Arnaud: think this means we're staying with b
18:50:35 [pano]
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.
18:51:19 [pano]
... we've only seen one example, and we need more to be convinced.
18:52:12 [pano]
Arnaud: Shapes being collection of constraints, which Jim mentioned, is an explanation I like.
18:53:24 [pano]
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
18:53:48 [pano]
Arnaud: So, Holger will make a proposal with example
18:56:05 [pano]
... Issue 137 says that the spec doesn't address on of the use cases; for language tags
18:56:25 [kcoyle]
18:56:30 [Arnaud]
ack kcoyle
18:57:30 [pano]
Karen: things we want to do:
18:57:34 [hknublau]
18:57:38 [pano]
... 1. literal must have a language tag
18:57:49 [Arnaud]
ack hknublau
18:57:53 [pano]
... 2. literal must have a specific language tag
18:58:56 [pano]
... 3. no language can be used more than once
18:59:20 [pano]
Holger: 3 can be covered using uniqueLang
18:59:31 [pano]
1 is also covered
18:59:42 [pano]
... so it's only 2
19:00:36 [pano]
... one could be to do language IN
19:00:47 [Arnaud]
19:00:47 [trackbot]
issue-137 -- Missing constraint for language tag -- open
19:00:47 [trackbot]
19:00:54 [pano]
... another would be to use a pattern
19:01:09 [AndyS]
langMatches(...) in SPARQL
19:01:17 [Arnaud]
19:01:30 [pano]
Karen: I think also complex language codes need to be covered, not just the 2 or 3 letter language codes
19:01:47 [pano]
Arnaud: Seems like the solutions are not very complicated
19:01:48 [pano]
19:02:09 [pano]
... we just need to make a decision on which path to take
19:03:17 [pano]
... I'm inclined to keep it simple and try to make a proposal which addresses the most basic use cases
19:04:18 [pano]
Holger: In my email there is an example with langShape. The other option would be to leave it to the extension mechanism
19:04:39 [Dimitris]
I would prefer a simple solution and leave complex handling to extension mechanisms
19:05:08 [pano]
Karen: So that is for the issue 2.
19:05:30 [pano]
... I was thinking of solving 1. and 3. in the primer
19:05:46 [Dimitris]
I am not sure id we have use cases to justify a complex solution like sh:langShape
19:07:02 [pano]
Arnaud: Do we want to talk about issue-139?
19:07:53 [pano]
Dimitris: we shouldn't decide on this too late, because it can have impact on the syntax
19:08:53 [kcoyle]
19:08:58 [Arnaud]
19:08:58 [trackbot]
issue-139 -- Can all constraint properties be applied in all scenarios? -- open
19:08:58 [trackbot]
19:08:59 [pano]
Arnaud: I think we had a strawpoll and the result was that we wanted to investigate this further
19:09:39 [Arnaud]
ack kcoyle
19:09:57 [pano]
Karen: I would need to have a better idea of what changes in shacl
19:10:25 [Dimitris]
19:10:31 [Arnaud]
ack Dimitris
19:10:41 [pano]
Dimitris: it will make the spec a little bit simpler
19:11:20 [pano]
... now we have a table in section 4. If we say that all constraints are applicable everywhere, this removes the need for the table.
19:11:40 [pano]
... it does mean that some constraints would not makes sense, which should be explained
19:11:57 [Arnaud]
19:12:28 [kcoyle]
19:13:29 [pano]
Karen: What, if anything, does it do to the contraint components and supporting contexts?
19:13:44 [hknublau]
19:13:59 [pano]
Dimitris: This is a recap of the table, so this would also be removed
19:15:12 [Arnaud]
ack hknublau
19:15:38 [pano]
Holger: I agree that we could remove some words from the spec, but then we have to add words elsewhere
19:16:10 [hknublau]
19:16:22 [pano]
If we allow contraints everywhere then a spec implementer should create extra checks
19:17:07 [pano]
... there is a distinction between set based constraints and node based contraints, which is useful for the user
19:17:51 [pano]
Arnaud: Eric, what is the ShEx view on this point?
19:18:23 [pano]
ericP: ShEx has a more generalised model
19:18:26 [hknublau]
Much of the generalization was already achieved by merging sh:inverseProperty into sh:path
19:18:46 [pano]
Arnaud: Do you feel this makes the implementation more complex?
19:19:02 [pano]
ericP: It makes it less code, but it makes it harder to write that code
19:20:42 [pano]
... 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
19:21:24 [Arnaud]
STRAWPOLL: a) make constraint properties applicable in all scenarios, b) no, keep it the way it is
19:21:40 [hknublau]
a: -1 b: +1
19:21:57 [kcoyle]
a: +1 b:-.8
19:22:07 [jamsden]
a: -.5 b: +1
19:22:38 [Dimitris]
a) +1 b) -0.5
19:22:41 [AndyS]
19:22:49 [ericP]
a: 0 b: 0
19:22:53 [TallTed]
a: +1 b: +0
19:23:36 [pano]
Arnaud: Dimitris, can you explain your position
19:24:00 [pano]
Dimitris: I think it makes things simpler for the spec and for the user
19:24:48 [pano]
... 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
19:25:20 [Dimitris]
19:25:54 [Arnaud]
ack Dimitris
19:25:56 [pano]
Arnaud: I know Holger's position is that you shouldn't allow a use constraints in places that don't make sense
19:26:17 [pano]
Holger: And I also haven't yet seen an implementation in sparql with one query
19:27:52 [pano]
Arnaud: I find it interesting that Dimitris has changes position. I think Dimitris and Holger should continue the discussion
19:28:54 [pano]
... I feel we need to solve this.
19:30:33 [pano]
Arnaud: We're out of time. Please look at Dimitris' proposal on issue-150
19:33:21 [Arnaud]
trackbot, end meeting
19:33:21 [trackbot]
Zakim, list attendees
19:33:21 [Zakim]
As of this point the attendees have been Dimitris, Arnaud, kcoyle, marqh, AndyS, TallTed, pano, hsolbrig, hknublau
19:33:29 [trackbot]
RRSAgent, please draft minutes
19:33:29 [RRSAgent]
I have made the request to generate trackbot
19:33:30 [trackbot]
RRSAgent, bye
19:33:30 [RRSAgent]
I see no action items