IRC log of shapes on 2015-11-05

Timestamps are in UTC.

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