18:56:12 RRSAgent has joined #shapes 18:56:12 logging to http://www.w3.org/2015/11/05-shapes-irc 18:56:14 RRSAgent, make logs rdf-data-shapes 18:56:14 Zakim has joined #shapes 18:56:16 Zakim, this will be SHAPES 18:56:16 I do not see a conference matching that name scheduled within the next hour, trackbot 18:56:17 Meeting: RDF Data Shapes Working Group Teleconference 18:56:17 Date: 05 November 2015 18:57:00 simonstey has joined #shapes 18:59:20 pfps has joined #shapes 18:59:42 present+ pfps 18:59:50 present+ 19:00:03 present+ 19:00:04 present+ 19:00:41 present+ 19:01:04 present+ hknublau 19:01:51 Labra has joined #shapes 19:03:18 agenda: https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2015.11.05 19:03:21 chair: Arnaud 19:03:27 scribe: Labra regrets: Dimitris 19:04:14 start with the minutes 19:04:21 topic: Admin 19:04:21 PROPOSED: Approve minutes of the 29 October Telecon: http://www.w3.org/2015/10/29-shapes-minutes.html 19:04:31 aryman has joined #shapes 19:04:35 minutes looked OK to me 19:04:39 RESOLVED: Approve minutes of the 29 October Telecon: http://www.w3.org/2015/10/29-shapes-minutes.html 19:04:46 present+ aryman 19:05:09 aryman, can you mute? 19:05:11 we will have meeting next week 19:05:23 and there is a time change in the USA 19:05:53 both most of US and most of Europe have gone back to standard time topic: Disposal of Raised Issues 19:05:58 PROPOSED: Open ISSUE-105, ISSUE-106, ISSUE-107, ISSUE-108, ISSUE-109, ISSUE-110 19:06:01 Arnaud: proposes to open all the issues 19:06:09 one moment 19:06:44 +1 to open them all 19:06:55 all mine therefore all worthy :-) 19:07:15 +1 19:07:19 +1 19:07:22 +1 19:07:28 +1 19:07:28 +1 19:07:59 RESOLVED: Open ISSUE-105, ISSUE-106, ISSUE-107, ISSUE-108, ISSUE-109, ISSUE-110 19:08:16 present+ TallTed 19:08:41 hsolbrig has joined #shapes 19:08:48 present+ hsolbrig 19:09:02 topic: ISSUE-84: Allowed IRIs 19:09:02 ISSUE-84 -- Constraint to limit IRIs of focus nodes to a given enumeration (similar to owl:oneOf) -- open 19:09:02 http://www.w3.org/2014/data-shapes/track/issues/84 19:09:25 I'm sh:in with that 19:09:33 proposal to close it 19:09:56 PROPOSED: Close ISSUE-84, node constraints are now addressed with sh:in 19:09:58 +1 19:09:59 +1 19:10:00 +1 19:10:00 +1 19:10:04 +1 19:10:08 +1 19:10:08 +1 19:10:09 +1 19:10:13 +1 19:10:37 RESOLVED: Close ISSUE-84, node constraints are now addressed with sh:in 19:10:41 right, the proposal just says that sh:in solves the problem 19:11:21 topic: ISSUE-88: qualifiedValue 19:11:21 ISSUE-88 -- Should we add sh:qualifiedValue ? -- open 19:11:21 http://www.w3.org/2014/data-shapes/track/issues/88 19:11:29 PROPOSED: Close ISSUE-88, no longer needed - sh:qualifiedValueShape can now be applied to literals too. 19:11:35 +1 19:11:37 +1 19:11:40 +1 19:11:55 +1 19:11:56 +1 19:12:01 Labra: i have no problem closing it now that we have another way to solve it 19:12:02 +1 19:12:07 +1 19:12:09 +1 19:12:23 +0 19:13:47 aryman: asks if valueShape can be applied to literals 19:14:05 Holger: yes, it can be applied as you can define a shape as a constraint on nodes 19:14:31 agreed, the wording is clumsy, but the problem is solved 19:14:32 aryman: valueshape points to a shape and it defines a shape that applies to a literal 19:15:23 "shapes can be applied to literal" is fine by me 19:15:25 aryman: suggests a better wording 19:15:41 +1 19:15:42 RESOLVED: Close ISSUE-88, no longer needed - sh:qualifiedValueShape can be used with a shape that applies to literals 19:15:47 +1 19:15:53 +1 19:16:09 +1 19:16:15 +1 19:16:19 topic: ISSUE-61: Direction of sh:nodeShape 19:16:19 ISSUE-61 -- Direction of individual scoping: sh:nodeShape vs. sh:individualScope -- open 19:16:19 http://www.w3.org/2014/data-shapes/track/issues/61 19:17:39 q+ 19:17:48 q+ 19:18:08 Issue 61 is *only* about the direction of the link 19:18:30 ack aryman 19:19:13 aryman: I am ok with the vocabulary change because it was not consistent and now it covers literals 19:19:31 ...but I don't like the phrasing that scopeNode lives in the shapes graph 19:19:52 ...we have to make a distinction between the physical graph 19:20:13 ...an application can construct an augmented shapes graph 19:20:21 ...it doesn't know about the data 19:20:35 ack pfps 19:20:37 ...you add a scopeNode triple to the shapes graph when validating 19:20:58 pfps: Issue-61 is not about where the triple is 19:21:21 Arnaud: there are more than one proposals 19:21:34 ...we are not in the business to decide where the triples live 19:21:42 q+ 19:21:55 ...we can separate in two points... 19:22:01 ack pfps 19:22:05 PROPOSED: Close ISSUE-61, replacing sh:nodeShape with sh:scopeNode, which points from a shape to a node 19:22:08 ...the we can specify where the triples live 19:22:17 s/the/then/ 19:22:17 +1 19:22:19 +1 19:22:21 +0.5 19:22:24 +1 19:22:25 +1 19:22:29 +0 19:22:32 +0.5 19:22:40 +0 19:22:55 -1 19:22:55 i am muted 19:23:13 apparently I have a very sensitive mic 19:23:33 hknublau: I am re-reading about the issue and the last part is where the triple has to live 19:23:35 q+ 19:23:37 PROPOSED: replacing sh:nodeShape with sh:scopeNode, which points from a shape to a node 19:23:54 +1 19:23:55 +0.5 19:23:55 +1 19:23:58 ack pfps 19:23:59 Arnaud: yes, we can separate in two parts 19:24:27 pfps: suggest to have that as a separate issue 19:24:52 s/suggest/proposes/ 19:25:09 q+ 19:25:11 the node being validated 19:25:41 +0 19:25:48 +1 19:25:49 scopeNode says that the scope of this shape is this node 19:26:00 ack aryman 19:26:06 +0 19:26:21 aryman: it's not a single value, you can have several 19:26:50 ...the terminology must be consistent..if we have scopeClass we have scopeNode 19:27:18 Arnaud: we remove the closing part of the issue 19:27:22 RESOLVED: replacing sh:nodeShape with sh:scopeNode, which points from a shape to a node 19:27:43 q+ 19:27:46 Arnaud: second part when we can discuss where the triples live 19:28:03 ...can we agree on that? 19:28:10 ack aryman 19:28:12 q+ 19:28:45 input to the SHACL *validation* process! 19:28:50 aryman: I think what we are defining is what is the input to the SHACL processor, it should be two graphs the data graph and the shapes graph and neither has to be a physical graph 19:29:29 ...so I think we should that those graphs are logical or conceptual graphs and that how they are constructed is application specific 19:29:45 ack pfps 19:29:47 ...and along as we follow that way I am happy with scopeNode as is 19:29:54 pfps: agrees with Arthur 19:30:05 q+ 19:30:38 aryman: I would phrase saying that the input to the shacl processor...processor will do something if they are in the shapes graph 19:30:47 the inputs to the SHACL validation process are the shapes and the data graph ... these inputs are assembled in advance of starting the validation process per se 19:31:09 the inputs to the SHACL validation process are the shape information and the data graph ... these inputs are assembled in advance of starting the validation process per se 19:31:17 q+ 19:31:53 aryman: in practice a shacl processor will create a model in the sense of jena 19:31:59 PROPOSED: sh:scopeNode triples need to be in the shapes graph at processing time 19:32:10 +1 19:32:12 ack TallTed 19:32:25 +1 19:33:29 TallTed: I don't disagree with it and it seems that we need a clear definition of these terms and process...what are the inputs and what are the outputs 19:33:45 ack pfps 19:34:19 pfps: I agree with Ted and we need some overall description of what's going on 19:34:29 ...the shacl validation process 19:34:41 ..."this is how shacl validation works" 19:34:48 +1 to pfps comments 19:34:58 ...when the shacl validation process kicks off there are shapes and data 19:35:07 ...how you get there is a different matter 19:35:52 q+ 19:35:54 ...in any external document the surrounding of the validation process for example verifying web processes starts syntactically constructing those triples 19:36:20 ...by the time you get to the validation process you have shape information and a data graph and you have to validate that... 19:36:31 PROPOSED: sh:scopeNode triples need to be in the shapes graph at validation time 19:36:44 the process flow that I use is as follows - the task is to determine whether some data conforms to some shapes - the data graph is then consructed (somehow) and the shape information is gathered together and then validation starts 19:37:05 PROPOSED: sh:scopeNode triples need to conceptually be in the shapes graph at validation time 19:37:10 +1 19:37:12 +1 19:37:17 +1 19:37:18 +1 19:37:19 +1 19:37:28 +0 19:37:34 +0 19:37:49 +0 19:38:05 We can now also close the ISSUE 19:38:16 Close it, close it! 19:38:23 +1 close 19:38:24 close it 19:38:31 RESOLVED: sh:scopeNode triples need to conceptually be in the shapes graph at validation time, then close ISSUE-61 19:38:31 ok by me 19:38:51 ** is there any sound? 19:38:53 ** I can't hear anyone talking... 19:38:59 q- 19:39:29 q+ 19:39:30 q+ topic: ISSUE-100: sh:index 19:39:33 PROPOSED: Close ISSUE-100, adding sh:index as proposed 19:39:34 +1 19:39:39 ack hknublau 19:41:21 Labra_ has joined #shapes 19:41:39 q+ 19:41:54 ** I was disconnected, maybe you have to assign me as scribe again? 19:42:00 ack pfps 19:42:27 pfps: I don't like adding something that is not related to the validation process 19:42:32 q+ 19:43:08 q+ 19:43:11 q+ to propose "informative" 19:43:13 ack aryman 19:43:15 ...we need to have some notion and some tools that actually use it in some compatible phasion 19:43:33 aryman: so this property is useful for form building which is one of the use cases 19:43:54 without compatible implementation these properties will not pass the W3C barrier for recommendation 19:44:00 ...it doesn't contribute to validation but there are other properties like sh:default that are also useful 19:44:13 scribenick: Labra_ 19:44:33 ...I think this kind of property is only useful for generic form builders which will rely on any predefined value 19:45:14 10 GOTO 10 19:45:17 I am ok with xsd:decimal. 19:45:23 ...having an integer is probably too restricted 19:45:31 ack TallTed 19:45:35 ...maybe allow some other value for ordering 19:46:22 TallTed: I am also ok with other numberings...about the argument of implementation, we don't implement and then come back con a spec 19:47:15 ack hknublau 19:47:16 Arnaud: we can make this not mandatory 19:47:35 +1 19:47:39 oops 19:47:41 q+ 19:47:44 hknublau: all of shacl can be used in different contexts 19:47:53 @pfps how about quaternions so we could do 3D animation 19:48:00 q+ 19:48:06 ack ericP 19:48:06 ericP, you wanted to propose "informative" 19:48:10 ...when I introduced sh:index I put an example of sparql 19:48:27 I failed to speak also : this is not only about GUI tools. greenscreen form building can also be informed by SHACL. 19:48:38 ericP: I am sympathetic that this is going to be difficult to test 19:48:46 ...that said it may be useful 19:48:53 ...and we can maintain it as informative 19:49:02 ack hsolbrig 19:49:11 ...it can provide with the expressivity that can be useful 19:49:22 hsonbrig: asks if this is a way to introduce ordering 19:49:34 q+ 19:49:38 ...why and when do we introduce lists instead of sh:index ? 19:49:46 s/hsonbrig/hsolbrig/ 19:50:03 q- 19:50:12 hknublau: having an rdf:list it may be difficult and it is simpler to use sh:index 19:50:43 q+ 19:51:26 hsolbrig: we need to be careful when we introduce ordering and when we use one for the other 19:51:36 ...there needs to be more substantial 19:51:57 ack pfps 19:52:01 Arnaud: we list the use when possible but when not possible we look for other ways 19:52:28 s/list the use/use list/ 19:52:29 pfps: so we have a use case that talks about UI but we have no documents to say what the UI SHACL is usful for 19:52:53 s/look for other ways/use an index/ 19:52:57 q+ 19:53:04 ...without that this looks like decoration... 19:53:11 q+ 19:53:41 pfps: we can go forward with it in 19:53:55 see UC11: Model-Driven UI constraints 19:54:06 if somebody believes that UI is one of the use cases for SHACL then there should be some document explaining it 19:54:34 ...if somebody cares about the UI aspect of SHACL then that person has to write some stuff 19:54:47 q- 19:54:53 ...so when it is done we can say this is what this non-validation aspect of shacl is for 19:55:07 i was going to argue with pfps, but it turns out i agree that we should write some loose guidance 19:55:23 see also UC31: LDP: POST content to container of a certain shape 19:55:30 "automatic form generation, whether GUI or CLI or otherwise, is likely to make use of sh:index, rdf:label, rdfs:comment, potentially rdf:description." done. 19:56:04 arnaud: nothing says that if we put something in the spec now, then it must be in the recommendation 19:56:10 ack aryman 19:56:17 ...but doesn't seem to be enough to say that we should remove it now 19:56:49 we don't need an implementation now, but having neither an implementation nor even a loose specification means that it impossible to determine whether the solution is going in the right direction at all 19:56:53 ack TallTed 19:56:54 aryman: lists are closed containers when you know exactly the things 19:57:42 would it make sense to label it as "sh:order" to differentiate it from index as a key? 19:57:46 TallTed: Several people in this conversation have said how this can be used 19:57:51 so let's have someone write the document 19:57:56 q+ 19:57:57 PROPOSED: Close ISSUE-100, adding sh:index as proposed 19:58:16 sh:order may actually be better 19:58:17 ack pfps 19:59:10 pfps: asks that someone write that document...without any notion about what is the need then there is no point 19:59:38 pfps: there are lots of ways of defining UIs 19:59:58 Arnaud: how can this be bad if it is informative 20:00:05 q+ 20:00:13 ack hknublau 20:00:14 pfps: it produces a linear ordering 20:00:22 A linear *partial* ordering -- it is not required or required to be unique 20:00:23 q- 20:00:34 hknublau: we have been using that for years 20:01:08 q+ 20:01:34 PROPOSED: Close ISSUE-100, adding an informative sh:order as a decimal, specifying a linear ordering 20:01:34 my UI generator uses taylor series expansions to generate fractally recursive Xforms. 20:01:42 the user can never finish. 20:01:58 or start 20:02:10 I agree with pops wrt to grouping data items. At least one level of hierarchy is typical. 20:02:26 s/pops/pfps/ 20:02:50 pfps ... aka "pops" 20:03:05 auto-correct strikes again 20:03:56 Pops Patel-scheider 20:04:03 Arnaud: there is a proposal that seems to be fairly modest trying to add something that may be useful for users 20:04:09 ack aryman 20:04:13 ...we can change this later 20:04:21 kcoyle, feel like pinging Kai about UI use cases? 20:05:10 aryman: what we are talking is about a very modest feature that can be helpful 20:05:34 ...this seems a very low cost that has some benefits that satisfies that additional cost 20:05:38 +1 20:05:39 PROPOSED: Close ISSUE-100, adding an informative sh:order as a decimal, specifying a linear ordering 20:05:42 -1 there needs to be some document describing what UI/UX stuff this is addressing 20:05:56 +0.5 20:05:58 +0 20:06:08 -0.5 20:06:15 +.75 20:06:19 +1 20:06:22 +0.5 20:06:28 +1 20:06:51 PROPOSED: Close ISSUE-100, leaving out sh:index 20:06:55 -1 20:06:56 -1 20:06:59 +1 20:07:02 +0 20:07:03 -0 20:07:06 -.5 20:07:11 there *could* be some document that says that all the non-validation stuff is only for a simple domain-indepent nurd interface 20:07:13 +0 20:07:14 0 20:07:15 -0.5 20:08:09 topic: ISSUE-22: Recursion 20:08:09 ISSUE-22 -- Treatment of recursive shape definitions -- open 20:08:09 http://www.w3.org/2014/data-shapes/track/issues/22 20:08:19 I see it as a part of SHACL formatting -- a spec unto itself... 20:08:26 q+ 20:08:58 ack aryman 20:10:02 aryman: there are two documents which propose recursion 20:10:22 ...Iovka and Eric covered them...there were some issue on them 20:10:40 ...the last time Iovka said that she had abandoned that document 20:11:09 Holger also has proposal for how recursion could work 20:11:10 ...if you intend to do something with that document then your proposal for recursion is well founded and it produces the right result 20:11:25 ...but if you are going to drop it, I would propose something else 20:11:36 I would say instead that the proposal for recursion over negation in "Iovka's document" is very complex 20:11:43 ericP: we are still using the concept of well formedness in all ShEx implementations 20:12:09 ...you could go to stratification to obtain a less conservative notion of negation 20:12:15 q+ 20:12:36 ...so yes, we are maintaining it 20:13:01 aryman: I posted some question on this to the mailing lists that were not answered 20:13:07 ...how much time you need 20:13:35 ...if we haven't started conversation then I would propose a different thing 20:14:08 ...I raised some issues that are in the document that appears in the wiki...in section 6 20:14:11 Look at Section 6: Issues of http://arxiv.org/abs/1511.00384 20:14:32 ack pfps 20:14:39 ...those are the problems...they could be typos or they are things that I didn't understand 20:15:11 pfps: I make the same comment, I have some questions about the document...how recursion works is defined in a complex way 20:15:49 ...the document is well founded but it is not clarified 20:16:13 s/clarified/stratified/ 20:16:22 ...I don't anybody would want to do that but it's definitely a very complicated 20:16:44 q+ 20:16:57 ack pfps 20:16:57 s/I don't anybody/I don't know why anybody/ 20:17:21 pfps: there was this case with recursion with examples and now I can't find that page again 20:17:35 ...does anybody knows where it is? 20:17:39 https://www.w3.org/2014/data-shapes/wiki/ISSUE-66:_SHACL_spec_ill-founded_due_to_non-convergence_on_data_loops 20:19:17 ISSUE-93: engine / language 20:19:17 ISSUE-93 -- SHACL engine vs. SHACL instance requirements -- open 20:19:17 http://www.w3.org/2014/data-shapes/track/issues/93 20:19:57 Arnaud: what is a SHACL engine? 20:20:06 ...a validation engine or are there other use cases 20:20:23 ...there are other use cases...documentation, form generation and validation 20:21:13 Arnaud: how do we make progress on this issue? 20:21:25 q+ 20:21:30 ack hsolbrig 20:21:32 q+ 20:22:10 hsolbrig: the earlier discussion reminded me of XSL where it was divided in to XSL FO and XSLT 20:22:27 ...I wonder if there should be two parts 20:22:33 q+ 20:22:44 ...since we are focusing on validation...we may focus in that aspect 20:23:00 ack pfps 20:23:51 pfps: another pragmatic thing to do would be to not say that shacl validation engine is very specific...forget about engine and just say process 20:23:59 ack TallTed 20:24:07 TallTed: I support that idea from peter 20:24:24 ...we haven't seem anything about formatting 20:24:39 ...something like this is a radio button, ... 20:25:00 q+ 20:25:21 ...this is a semantic validation...the form builder is not part 20:25:25 +1 to Ted 20:25:43 the current spec is 99.44% about validation 20:26:04 q+ 20:26:15 TallTed: maybe we don't need to add much more complexity to cover documentation or form building 20:26:40 ack hsolbrig 20:26:41 TallTed: by documentation I mean description of data 20:27:08 documentation use case applies to the description of Linked Data APIs 20:27:27 hsolbrig: just a clarification, one of the things that popped of the index discussion is that we can use the sh:index for an ordering function that can be used for something else 20:27:47 ...we may end up adding things that may be used for incompatible things 20:27:55 from the charter, 3 bullets which lack the first words here -- 20:27:55 • Documentation == Defining and publishing a description of the intended topology and value constraints of nodes in an RDF graph, henceforth a "shape". 20:27:55 • Validation == Verification of data integrity with respect to a shape. 20:27:56 • UI/UX == Human and machine interpretation of shapes to develop or optimize SPARQL queries and develop user interfaces. 20:28:04 ...if we are going to do form building we may be more specific 20:28:55 ack pfps 20:29:25 Arnaud: it may be useful to remind what is in the charter 20:29:41 q+ 20:29:42 ...we are expected to address those points 20:29:43