RDF Data Shapes Working Group Teleconference

21 Apr 2016


See also: IRC log


Arnaud, kcoyle, simonstey, pfps, labra, Dimitris, jamsden, TallTed, ericP, markh, hknublau
pfps_(partial), hsolbrig


<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

Disposal of Raised Issues

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


<kcoyle> +1

<Dimitris> +1



<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


<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


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


<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


<pfps> +1

<kcoyle> +1

<simonstey_> +1

RESOLUTION: Close ISSUE-129, as addressed by the change of sh:notEquals to sh:disjoint



<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


<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


<Labra> +1

<simonstey_> +1

<TallTed> +1

RESOLUTION: Close ISSUE-124, as addressed by the current draft



<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

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 14 April 2016 Telecon: http://www.w3.org/2016/04/14-shapes-minutes.html
  2. Open ISSUE-148, ISSUE-149, ISSUE-150, ISSUE-151
  3. Close ISSUE-101, as no longer relevant.
  4. Close ISSUE-144, addressed in the latest draft
  5. Close ISSUE-125, as fixed in the latest draft.
  6. Close ISSUE-129, as addressed by the change of sh:notEquals to sh:disjoint
  7. Close ISSUE-57, group cardinality won't be addressed in this version of SHACL
  8. Close ISSUE-124, as addressed by the current draft
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.143 (CVS log)
$Date: 2016/04/29 15:54:45 $