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