RDF Data Shapes Working Group Teleconference

27 Aug 2015


See also: IRC log


Arnaud, simonstey, hknublau, dimitris, kcoyle, ericp, TallTed, hsolbrig, scott, shenninger
aryman, pfps, labra



<Arnaud> PROPOSED: Approve minutes of the 20 August Telecon: http://www.w3.org/2015/08/20-shapes-minutes.html

<kcoyle> none

RESOLUTION: Approve minutes of the 20 August Telecon: http://www.w3.org/2015/08/20-shapes-minutes.html

Arnaud: iovka has set up badges and directions
... i took a pass at the agenda
... the agenda will probably evolve over time
... let's look at the time frame and the objectives
... folks need to know what we need to cover, but i want you to tell me if i'm missing something
... the time slots don't matter so much as makking sure there's a placeholder for everything we need to cover
... the main piece is of course the shacl spec itself
... i expect to take advantage of the increased bandwidth to resolve issues
... we have an open action item to try to publish FPWD next week
... by the end of the meeting we should know what we need to do to get a CR
... (we can have other working drafts in the process)
... we deferred pulishing a couple things: vocab and @@1
... we need to know how to create a test suite by the end of the meeting
... for now we have holger who has been editing and implementing
... it's unclear how much expressivity we can get from shacl
... i don't want to delay working on the compact syntax because it may impact the lower level
... we don't have much flexibility for lunch time so we have to be firm on the meeting start time (4am US west coast)
... we'll go until 6pm
... we may want to spend more time on the user-friendly syntax if we get into tech discussions
... we have a lot of time for shacl issues so that serves as a buffer
... (the only thing i'm sure of is that there will be shacl issues.)

hknublau: the meeting will end very late for me (3am)
... if there are topics where i'm needed less, i'd like them at the end
... e.g. test suite or compact syntax

Arnaud: understood, though i also want a buffer for them to overrun


simonstey: when Axel and I read the spec we ran across the defn of qualified value shapes

<Arnaud> issue-83

<trackbot> issue-83 -- How should multiple definitions of sh:qualifiedValueShape of a property constraint be treated? -- raised

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/83

simonstey: in the current spec there is no clarification saying that you are only allowed one qualified value shape per property
... if you have several qualified value shapes, then one would trigger for all matching triples
... you'd have to define two property constraints to cover that.
... the API should raise an error if you have more than one qualified property constraint.
... i'm still concearned that the qualified{min,max} does not appear in the property constraint

Arnaud: ok to open the issue?

<Arnaud> PROPOSED: Open ISSUE-83: multiple sh:qualifiedValueShapes


<Dimitris> +1

<kcoyle> +1

<TallTed> +1

<simonstey> +1

<hsolbrig> +1

<hknublau> 0

RESOLUTION: Open ISSUE-83: multiple sh:qualifiedValueShapes

Arnaud, should we discuss issue-70, noting that pfps isn't here?

scribe: skipping for today


<Arnaud> issue-51

<trackbot> issue-51 -- What types of validation results should be returned -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/51

Arnaud: the question is about how the results are reported to the calling application.

kcoyle: said she was concearned that success was signalled by silence

hknublau: in a sense, i agree

<Dimitris> +q

hknublau: i think the vocabulary should @@2
... it should say that shapeX was executed succussfully
... if only for recording what happened
... the last time we talked about it, i had a proposal on a branch.
... i implemented what Dimitris suggested: the three error levels (implemented as severity classes)
... there are validation results
... there are errors for e.g. recursion not supported
... and there's success, which defaults to no message

<TallTed> I'd prefer that the success objects be generated by default (with switch available to not). silence is rarely as useful as positive affirmation.

hknublau: pfps made an alternate proposal, but we decided later it was too simplistic

Arnaud: why is success only returned as an option?

hknublau: there could be thousands of successes
... since everything goes into a results graph, it could entail too much in that graph

Arnaud: kcoyle, you said you want to know the difference between the successful validation vs. the machine stopped.
... so a boolean flag would work

kcoyle: fine for me, i can imagine developers would want to see more

Dimitris: hknublau mostly covered me
... reporting only errors is frequently errors, but yes we sometimes need to see what was validated
... happy for the default to be silent success

TallTed: i'd like simple success to be the default because silence doesn't tell me that the process was run

hknublau: isn't that outside of the spec?
... there's some API that's called and when the caller gets no errors, it can do somethig on the interface.

TallTed: we need something like shell's return code

hknublau: [disagrees]

Arnaud: i agree that this is an API issue

+1 to API issue

hknublau, the branch is pretty up-to-date but also has numeric severity levels (which can be dropped)

Arnaud: can you clean up that branch and send it to the list?

simonstey: even a test that succeeds can have a severity level

hknublau: by following the link back to the constraint, you can get the severity

simonstey: then maybe we should remove it from errors as well

Arnaud: does what he's describing sound reasonable to people?

<kcoyle> works for me

Arnaud: we went back and forth between a system that was too limited and one that was too complicated.
... i think what hknublau just described is where we left it
... i know that pfps may have issues about the class hierarchy
... but we should agree on the basic idea
... welcome Scott Henninger (Dean Alemang's group)


<Arnaud> issue-74

<trackbot> issue-74 -- Should SHACL support validating RDF graphs accessible via unmodified SPARQL endpoints -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/74

Arnaud: pfps raised this, but hknublau, can you introduce it?

hknublau: there's a SPARQL Protocol to talk to databases over the web
... the question is whether all the shacl constructs need to work over such a connection
... the protocol has some limitations making it impossible to work with bnodes
... i propose that we don't require 100% compatibility with the protocol.
... we can have a separate deliverable which describes what of shacl you can and can't do

Arnaud: just the instance graph to be validated or the shapes graph or both?

hknublau: we still have a separate topic re: whether we can see the shapes graph
... there are several cases that cannot be solved without access to the shapes graph

Arnaud: this issue seems to be about the validation graph

hknublau: in principle, you can reduce everything to SPO queries
... but it's not very fast.

ericP: SPARQL doesn't have "told blank nodes"

Arnaud: i think pfps wanted us to say that is should be possible to execute SHACL with an unmodified SPARQL endpoint

TallTed: possible doesn't mean efficient

ericP: you can keep track of how you arrived at a bnode

hknublau: but if you get to bnodes, you can't tell them apart

ericP: true, but you also can't give a distinct validation result unless you've grabbed their properties

TallTed: this is an implementation detail.

hknublau: if we carelessly say yes, there are lots of things we have to change

TallTed: we could also say "if you can't see the whole graph, you can't validate shapes against it."
... the input to SHACL validation is a shape, a graph, and possibly some focus nodes in that graph
... the input is not a shape, a SPARQL endpoint, ...
... there are lots of graphs behind a SPARQL endpoint, but if the SHACL processor can't see the entire graph, then that graph is not an input

hknublau: i proposed to extend the SPARQL protocol to ship shapes to endpoints.

Arnaud: this reminds me of inferencing. we say that inferencing is outside of shacl.
... we can say the same thing for SPARQL endpoints

<hsolbrig> +q

hknublau: i would be happy to have a separate deliverable

<kcoyle> (Arnaud contemplates infinity)

hsolbrig: i like TallTed's assertion but i think it could be modified to say that shape validation can assume that the entire graph is visible
... we can spec it as if the whole graph is visible.
... however you want to make that happen is up to you.

<Dimitris> +q

+1 to hsolbrig's characterisation

Dimitris: i'm in favor of SPARQL endpoints, but i won't object. i'd like to minimize the damage as hknublau suggested

Arnaud: how much work is that?

hknublau: in the simplest form, we can have a paragraph that says "you can wrap an endpoint" and an appendix that enumerates limitations like access graphs

Arnaud: this is all informative

hknublau: yes

Arnaud: satisfied, Dimitris?

Dimitris: depends how the spec evolves.
... most of the spec can be formed for endpoints

Arnaud: i hear Dimitris saying we shouldn't arbitrarily make it hard for people to do this.
... but we're not bound by this constraint

<kcoyle> i can scribe temporarily

Arnaud: i can't imagine anyone is opposed to hknublau's proposal to add informative text

<kcoyle> oh, you're back

Dimitris: maybe an algorithm to do stuff in a single query

TallTed: i don't think that's possible

Arnaud: i'm happy for people to work on this, but i don't want to count on it
... we could publish a note
... for issue-74, we're going to answer with a "no" with the caveat that we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep this in mind so we don't make it arbitrarily difficult

<Arnaud> PROPOSED: Close ISSUE-74, answer is no but we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep in mind that some people will want to validate against an endpoint so we don't make it arbitrarily difficult

<hknublau> +1

<hsolbrig> +1 (although I think it should say "not always possible" vs. just not)

<kcoyle> +1

<TallTed> +1 "may but also may not be possible, depending on your graph and shape and ......"

<Dimitris> -0.9 for no +1 for informative text and easing sparql endpoint validation

Arnaud, Dimitris would you want to limit SHACL to what's implementable over a SPARQL endpoint?

<hknublau> Let’s not forget that SHACL also supports other languages than SPARQL.

Dimitris: i think it's a common use case, at least for me. this decision whittles out half of my endpoint

TallTed: how much of your data includes bnodes?

Dimitris: not much, but i don't want to put everything in memory

Arnaud: so maybe the right thing to do is to ship the shape to the endpoint

ericP: the sparql protocol is a red herring. SPARQL does not support told bnodes.

hknublau: i think we need a statement that bnodes have consistent identifiers
... most vendors have moved to stable identifiers

RESOLUTION: Close ISSUE-74, answer is no but we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep in mind that some people will want to validate against an endpoint so we don't make it arbitrarily difficult

hknublau: but ericP is right that SPARQL does not say bnodes have stable identifiers


<Arnaud> issue-81

<trackbot> issue-81 -- Shall SHACL Core include support for disjoint properties and other property pair constraints? -- open

<trackbot> http://www.w3.org/2014/data-shapes/track/issues/81

hknublau: we got feedback from the outside, which is always appreciated
... we got suggestions like two properties are disjoint

ericP: can a shape have properties :a and :b and either :c or :d

hknublau, this is about disjoint values

hknublau: this is about disjoint values

ericP: oops

<Dimitris> +q

TallTed: seems like a useful pattern, includeing < > ≠

Arnaud: we have an issue about ≠
... simon raised an issue about how to access another property
... but it seems that if we go down this route, we need the normal operators

<TallTed> "disjoint" is the wrong descriptor here -- "not equal" is the meaning from the issue

Dimitris: i would prefer to have < > ≠ = in the core library

kcoyle, the skos example is important for the cultural heritage community

scribe: saying that label and preflabel are ≠ or that the language tags have to be unique

Arnaud: if the issue you have ordered property constraint

<TallTed> "ordered" was about "greater/less than" -- date values...

hknublau: it's only to say that the first is smaller than the second

<TallTed> = ≠ ≥ ≤ < >

¬ ∧ ∨ ∀ ∃ ∄ ∅ ∈ ∊ ∉ ∋ ∌ ∍

<Arnaud> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

  1. Approve minutes of the 20 August Telecon: http://www.w3.org/2015/08/20-shapes-minutes.html
  2. Open ISSUE-83: multiple sh:qualifiedValueShapes
  3. Close ISSUE-74, answer is no but we'll add some informative text to the spec talking about the pitfalls of validating against a SPARQL endpoint and we should keep in mind that some people will want to validate against an endpoint so we don't make it arbitrarily difficult
[End of minutes]

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