See also: IRC log
<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
+1
<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