See also: IRC log
<Labra> ** ok
<scribe> scribenick: ericP
<Arnaud> PROPOSED: Approve minutes of the 14 April 2016 Telecon: http://www.w3.org/2016/04/14-shapes-minutes.html
<pfps> look ok to me
RESOLUTION: Approve minutes of the 14 April 2016 Telecon: http://www.w3.org/2016/04/14-shapes-minutes.html
Arnaud: appreciate pfps keeping track of things
<Arnaud> PROPOSED: Open ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151
Arnaud: 149 seems to be editorial so the editors can handle it
<TallTed> +1
<simonstey_> +1
<jamsden> +1
<Labra> +1
+1
<kcoyle> +1
<Dimitris> +1
RESOLUTION: Open ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151
<Arnaud> issue-101
<trackbot> issue-101 -- use of rdfs:subClassOf for template inheritance -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/101
<jamsden> +1
<Arnaud> PROPOSED: Close ISSUE-101, as no longer relevant.
<hknublau> +1
<TallTed> +1
Arnaud: sinnce we don't use subClassOf, let's close it
+1
<simonstey_> +1
<Dimitris> +1
<kcoyle> +1
<Labra> +1
RESOLUTION: Close ISSUE-101, as no longer relevant.
<Dimitris> we can also close ISSUE-144, Peter said it can be closed with e current spec
<trackbot> issue-144 -- substitution is sometimes used instead of pre-binding -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/144
<Arnaud> PROPOSED: Close ISSUE-144, addressed in the latest draft
dimitris: issue 144 was addressed in latest draft
<hknublau> +1
<Dimitris> +1
<jamsden> +1
dimitris: this was acknowledged by pfps who approved it being closed
<kcoyle> +1
pfps, you agree?
<simonstey_> +1
<TallTed> +1
<Labra> +1
+1
RESOLUTION: Close ISSUE-144, addressed in the latest draft
<pfps> +0.5, I don't see any offending "substitute" any more, but maybe there is some other similar word lurking around
<Arnaud> issue-125
<trackbot> issue-125 -- sh:NodeConstraint is mentioned but never defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/125
<jamsden> +1
<Arnaud> PROPOSED: Close ISSUE-125, as fixed in the latest draft.
pfps, do you believe this issue is addressed?
<hknublau> +1
<pfps> it looks as if there is an adequate description of the purpose of node constraint
<pfps> +1
<simonstey_> +1
<TallTed> +1
<Dimitris> +1
+1
<kcoyle> +21
<Labra> +1
RESOLUTION: Close ISSUE-125, as fixed in the latest draft.
<Arnaud> issue-129
<trackbot> issue-129 -- Existential constraints should be consistent -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/129
Arnaud: this wasn't just an issue of changing something in the draft
... we've discussed this before without resolution
... there was a push to do nothing
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-129:_Existential_constraints
Arnaud: the votes on the proposals page still reflects that
<Arnaud> PROPOSED: Close ISSUE-129, as is.
<jamsden> +1
<Dimitris> +1
<TallTed> +1
<hknublau> +1
+0
<pfps> +1
<kcoyle> +1
<simonstey_> +1
RESOLUTION: Close ISSUE-129, as addressed by the change of sh:notEquals to sh:disjoint
ISSUE-57
<trackbot> ISSUE-57 -- Cardinalities on expressions or groups of triple constraints -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/57
<Labra> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-57:_Group_cardinality
<Arnaud> labra: will add a lot of complexity, willing to give up on this for this version of SHACL
<Arnaud> ericP: sorry to give up on this
ericP: optional groups and (A | B | C)+ are common constraints
jamsden: these could be considered syntactic sugar
... seems good that ShEx adds value on that
... it is possible for us to describe the shapes on SHACL itself using cardinality, and iirc, we've agreed not to do that
... i'm ok with leaving this out for now.
<Arnaud> PROPOSED: Close ISSUE-57, this won't be addressed in this version of SHACL
<jamsden> +1
-0.5
<pfps> +0.9999
<Labra> -0.5
<kcoyle> +1
<simonstey_> -0.5
<TallTed> +0.5
<Dimitris> +1
<hknublau> 0.9999
RESOLUTION: Close ISSUE-57, group cardinality won't be addressed in this version of SHACL
<pfps> it would be nice to have this feature, but the pain is likely to be severe
Arnaud: wanted to see where we've gotten on this
<Arnaud> issue-68
<trackbot> issue-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
hknublau: my impression is that we've made progress but it's a matter of voting -- whether pfps can live with it or not
... seems to be about wording and not substance
... i don't see tenchical obstacles
Arnaud: i think pfps's last email said "i don't know what i need to implement"
... not sure if that's general or specific to this issue
<pfps> the current definition is still broken - it doesn't conform with how SPARQ works - SPARQL does not evaluate variables in basic graph patterns
hknublau: we could add some test cases using SPARQL-based constraints
... hard to judge without specific examples
Arnaud: given pfps's irc comment, i guess you need to continue working with him on this
jamsden: we asked if we had a definition of pre-binding that works
<pfps> test cases are only going to provide point examples - what is the basic thing that is going on? -can't depend on SPARQL implementations because their documentation is criminally deficient here
jamsden: not regarding the language of the spec
... (let's not worry about beauty at this point)
pfps, do you think there's still a substantial issue, separate from the documentation?
<pfps> as far as I can tell the only thing in this vicinity in SPARQL implementations that could be considered to be interoperable is texual subsitution, but that does not appear to be what is needed here
<pfps> yes, I still don't know what is supposed to happen - someone who knows SPARQL is going to have to take a look at all this - the description and the examples that are supposed to work, and figure out how to describe it
Arnaud: hknublau, can you explain this mechanism [for those here]?
<pfps> each time I look at it it takes me a minute or two to knock huge holes in it, but I don't know enough about SPARQL to proclaim that it will work right
hknublau: my approach does NOT work on text substitution
... i.e. replacing text in a SPARQL string
... i propose to go a level deeper
<pfps> except, of course, that I do know how textual substitution works, but that is not what appears to be wanted here
hknublau: define in terms of the SPARQL query as compiled to SPARQL algebra
... BGPs create bindings with filters limiting them
<pfps> of course, it would probably be possible to rewrite the SPARQL examples in the spec and the template implementations so that textual substitution (plus a way of stating bnodes) would work
hknublau: the approach would say that the binding flow that goes from step to step would include these bindings.
... we wouldn't limit the implementation approach
ericP: [description of BINDINGS definition in SPARQL Federation]
hknublau: doesn't work for BIND which can't e.g. add one to an unbound variable
ericP: that's true, with SPARQL Federation, you can't use a BIND directive using a variable that was passed in through the BINDINGS syntax
Arnaud: i think that hknublau has the burden of defining the mechansim so that others can understand it
ericP: the bottom-up algebra makes this extremely challenging
<Arnaud> issue-124
<trackbot> issue-124 -- sh:group is only mentioned in examples -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/124
Arnaud: pfps pointed out another construct that's not defined
... do the editors agree?
<hknublau> I think it's covered now
<kcoyle> section 3.9 - uses it, is that a definition?
Arnaud: hknublau, did you add something which defines this?
hknublau: yes, just search for the term. i believe it's there now
<pfps> a paragraph or so was added to 3.9 in response to this issue - given that sh:group doesn't actually do anything this paragraph is probably sufficient
ericP: i propose that the explainatory text make it clear that it's an annotation property
Arnaud: agreed. note that it doesn't play a role in validation
Dimitris: it's in a section about non-validating constraints
<pfps> it would be nice to see whether the whole order/group/whatever passes the "burst-of-laughter" test from someone who does interface design for a living
<Arnaud> PROPOSED: Close ISSUE-124, as addressed by the current draft
<pfps> +0
ericP: is "annotationProperty" a defined term and should we have it in P1 of 3.9?
hknublau: i wouldn't use it because folks will confuse it with owl:AnnotationProperty
<kcoyle> 6.4 annotations
Arnaud: i see it elsewhere
<pfps> sh:annotationProperty has a completely different meaning
hknublau: those are annotations on the results
<kcoyle> +1
<Dimitris> +1
<hknublau> +1
<jamsden> +1
Arnaud: ok, so we're probably better off not using "annotation property" for this
+1
<Labra> +1
<simonstey_> +1
<TallTed> +1
RESOLUTION: Close ISSUE-124, as addressed by the current draft
ISSUE-105
<trackbot> ISSUE-105 -- SHACL SPARQL constraints depend on namespaces in a graph, which is not defined -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/105
<pfps> https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-105:_Defined_prefixes
<Arnaud> ericP: tempting to reuse the prefixes from turtle when embedded in turtle
<Arnaud> ... but that's not RDF
<Arnaud> ... won't work when graph doesn't come from turtle
<pfps> also doesn't work (well) when the graph is cobbled together from different sources
ericP: three approaches:
<TallTed> it doesn't matter whether a *graph* is cobbled together from different sources. a *graph* has no prefixes!
ericP: 1 don't share prefix declarations between SPARQL literals in SHACL Turtle doc (do nothing)
... 2 define some pre-declared prefixes for parsing every embedded SPARQL literal
... 3 declare that SHACL is written in Turtle++Prefixes language which defines some API for getting at the prefix decls
<hknublau> We certainly need something like sh:prefix, tools can help users enter them.
Dimitris: one more:
<TallTed> how do these approaches align with the proposals?
Dimitris: special vocabulary to declare the prefixes in the graph
ericP: that's kinda slick, actually
<pfps> agreed that the graph doesn't have prefixes, but one might want to say that the prefixes are lifted from the document used to transfer the graph - but this doesn't work well either
Arnaud: there are 3 proposals on the proposals page, one acceptable
TallTed: we're not talking about graphs. a graph doesn't have prefixes. prefixes only exist in particular serializations
Arnaud: i don't think the question is whether prefixes exist in RDF; it's how do we deal with that?
TallTed: why is this SHACL's responsibility?
... we don't need another mechanism
hknublau: propose to close this adding sh:prefix
... the shapes graph would define those prefixes in a machine-readable form
... when you define e.g. an ontology, attach an sh:prefix arc
Arnaud: that would be in line with the proposals page
hknublau: in our own namespace, we add sh:prefix. in the SHACL vocabulary, we could pre-define a couple prefixes for ease of use
... tools can look for conflicts
TallTed: and then?
hknublau: invalid schema, we already have this
<pfps> an unquote mechanism would work nicely here - curies in the SPARQL strings in a SHACL document would be expanded as if they were node identifiers - however that opens up another can of worms
<Dimitris> if you import from external sources you may get a clash in a shape IRI as well
TallTed: so if i import from two external sources both of which declare the same prefix, i'm sunk?
hknublau: yes, worthwhile because users won't use SPARQL if we don't have pre-defined prefixes
TallTed: i'd rather use what some SPARQL engines use with pre-canned prefixes
... as soon as external people around the world are defining ontologies and wanting short prefixes
... if an engine wants to extend it, great
... if we can add it sideways, maybe folks can stick their prefixes in an external doc
<pfps> in the end, the only time that this matters is when writing SPARQL parameterized queries - it is astonishing to me that having to add prefix declarations to these queries, which are intellectually challenging to write, would be a severe problm
jamsden: to me, prefixes have no semantic meaning; they never appear in any graph; they are simply a syntactic shortcut used by various serializations
... each of these formats provides a conflict resolution [i.e. redefinition]
Arnaud: the prob is that in SHACL, you can embed SPARQL queries
... from an RDF perspective, these are just strings
<simonstey_> +q
<pfps> ... a reallly nice syntactic shortcut when writing lots of triples, but it's not as if there are going to be lots of triples in the SPARQL parameterized queries needed to implement SHACL templates
jamsden: who's writing them and when?
<simonstey_> -q
jamsden: it's extension mechanisms, right?
... like embedding C and not having a mechanism to expand macros
<markh> +q
<simonstey_> +q
jamsden: there's no context in which to share prefixes in string literals
markh: if i have a SHACL doc and I've included a SPARQL query (a string from the point of view of the doc), is it valid for me to include specific prefixes in the SPARQL literals?
hknublau, ericP: yes
<simonstey_> -q
markh: i don't see a huge value in factoring these prefix decls
<pfps> sure - the SPARQL string can define prefixes
jamsden: but you have to say them over and over because there's no context for sharing them
Arnaud: i'm seeing a growing do-nothing camp
... what's the scope of the sh:prefix proposal
TallTed: sh:import to import your prefixes file.
... this would have to be processed by the "SHACL parser"
hknublau: we have the concept of a shapes graph
... the construction of a shapes graph is outside our control
... it's the responsibility of the application to assemble it
... if someone wants to combose a shacl doc, they have control over the owl:imports, sh:prefix, etc
Arnaud: there's an sh:prefix proposal on the proposals page
... it would build a mapping table which is available for the SPARQL query parser
hknublau: i've implemented this over and over, i see no practical problem
... no one's forced to use it
Arnaud: sure, btu the question is "do you require implementations to support it"
<jamsden> What if the embedded extension isn't sparql, doesn't use XML style prefixes, but has some other import mechanism that needs to be supported e.g., packages?
<Arnaud> STRAWPOLL: a) do nothing - no prefix definition mechanism to SHACL, b) define some prefix definition mechanism
a:+1 b:-.5
<jamsden> a:+1, b:-.9
<hknublau> a: -1 b: +1
<TallTed> a: +1, b: -0.9
<kcoyle> a: +1 b:-.75
<Dimitris> a) -1, b) +1
<Labra> a: +1, b: -0.5
<simonstey_> a: +1 b: -0.9
<pfps> a: +1, b: -0
<markh> a: +1, b: -0.5
Arnaud: why do you -1 on nothing?
<simonstey_> +q
Dimitris: because it's a pain to write constraints without prefixes
... i know this first-hand
<markh> +q
Arnaud: what do you say to markh's point; practically speaking, you've got a SPARQL query you want to cut and paste which needs those prefixes
<pfps> actually it's a pain to write constraints, period - the added pain to put prefix declarations at the beginning of each of the is so minor in comparison
hknublau: but any SPARQL tool already had pre-defined SPARQL prefixes
<pfps> it's like we are saying that c programs get a set of predefined includes
simonstey_: i agree with jamsden other extension mechanism like packages wouldn't work with sh:prefix
<hknublau> For JavaScript people can add another property such as shjs:requireLibrary
simonstey_: if you use a serialization format like Turtle, can't you use the prefixes from Turtle?
<jamsden> but there's no semantics for applying prefixes in any syntax to object string literals
simonstey_: maybe that's too handwave-y, btu that would be a way to deal with that
<TallTed> +1 pfps re `predefined C includes`
markh: the impls that i use commonly provide pre-defined prefixes but they're embedded in the query.
... they're part of the query; the user can edit them with the query
... this encourages good practice
<simonstey_> +q
Arnaud: so we don't have concensus around doing nothing; we don't have any objections to continuing the investigation
<markh> +q
simonstey_: i agree with markh's; we define some default prefixes like rdf, rdfs, xsd
ericP: i thought that was in contradiction with markh's observation
<hknublau> Nobody is forced to use sh:prefix. I am disappointed about the votes that try to prohibit an optional feature.
simonstey_: we could be explicit about it
Arnaud: the 2nd proposal says that, if we agree on the first one, we can have a bunch of pre-defined ones
... but in fact it is not dependent on 1st proposal
markh: i don't think that's what i was proposing
... in my mind, i'd expect to see the prefix decls in every SPARQL query
<pfps> actually the second proposal says to have a bunch of pre-defined prefixes (rdf rdfs ...) and if there is a way of setting up prefixes then this can be done using that mechanism instead of just by fiat
<Arnaud> trackbot, end meeting