See also: IRC log
<pfps> Welcome Andy.
<AndyS> hello everyone.
<pfps> Remember, this system is not connected to Zakim the right way. :-(
<Arnaud> https://www.w3.org/2014/data-shapes/wiki/Meetings:Telecon2016.06.23
<pfps> The link works, but it still red
<pfps> I think that Arnaud copied the link when the page didn't exist
<pfps> Yeah this appears to be a caching problem, newly introduced
<scribe> scribe:jamsden
<Arnaud> PROPOSED: Approve minutes of the 16 June 2016 Telecon: http://www.w3.org/2016/06/16-shapes-minutes.html
<pfps> minutes look fine
RESOLUTION: Approve minutes of the 16 June 2016 Telecon: http://www.w3.org/2016/06/16-shapes-minutes.html
Arnaud not be available for the next meeting, Eric to chair
<pfps> 169 is a fine issue to open
<scribe> new raised issues: ISSUE-169 to rename scope and inverse property
<Arnaud> PROPOSED: Open ISSUE-169
<pfps> +1
+1
<hknublau> +1
<kcoyle> +1
RESOLUTION: Open ISSUE-169
look at open issues to establish a context for evaluating progress
determine if there are some issues that could be pruned
https://www.w3.org/2014/data-shapes/track/issues/open
<kcoyle> #93 may have been dealt with via edits
<ericP> Arnaud: we have 32 open issues; just opened another
Arnaud calling for volunteers to prune the list
<ericP> ... it might seem daunting
Arnaud: welcomes input on what issues to addres
hknublau: introduced sh:partion feature from Arthur. Evaluated. may be overlapping with other features.
related to issue 92
pfps: partition didn't provide composition of and and ors
... will look into resolving this
kcoyle: issue 93 and 137 were alread addressed?
<pfps> If anyone in the working group thinks that an issue has been resolved they should point this out by email so that the WG can check and resolve the issue
hknublau: not addressed yet.
requires additional analysis
<trackbot> ISSUE-168 -- How to constrain number of instances of a class in a graph -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/168
not sure we have common understanding of the problem or whether its addressed by the current spec
kcoyle: would prefer that classes not be used at all in SHACL, but if used, should be used consistently. predicate of rdf:type as a class needs to be treated that way throughout. Would prefer everything to be treated just as triples, including rdf:type
count instances of Class or rdf:type properties
hknublau: already to count based on rdf:type, cardinality constraint on inverse triples syntax exists. Don't have a clean feature to find instances of a subclass. minCount, maxCount would require extensions to nodeConstraint.
... compromise that doesn't require changes to nodeConstraint, instanceCount applied to scope node
kcoyle: can triples and subclasse be handled with Holger's proposal?
predicates with rdf:type shouldn't be treated in different ways
scribe: but don't need a specific solution to instance count
hknublau: many ways of triggering validations, minimize what is in core and use extension mechanisms as needed. Not covered in use cases so shouldn't be adding anything new at this time.
Arnaud: propose we close ISSUE-168
<Arnaud> PROPOSED: Close ISSUE-168, without adding min/maxInstanceCount as not motivated enough
<hknublau> +1
+1
<kcoyle> +1
<pfps> 0
<ericP> +1
RESOLUTION: Close ISSUE-168, without adding min/maxInstanceCount as not motivated enough
<trackbot> ISSUE-68 -- pre-binding not defined in SHACL spec -- open
<trackbot> http://www.w3.org/2014/data-shapes/track/issues/68
<pfps> pre-binding does not rely directly on exists, but exists is related to pre-binding
Arnaud: relying on something unstable in SPARQL
<pfps> The current definition of SPARQL has counterintuitive consequences for
<pfps> SHACL. One of these consequences is that even if pre-binding was fixed,
<pfps> sh:class would not work correctly. For example, even if pre-binding was
pfps: two related problems. ours and SPARQL, related because prebinding is close definition of exists which has problems. Almost all of SPARQL SHACL depends on exists. and it has problems.
<pfps> fixed sh:class would not work correctly because
<pfps> SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
<pfps> WHERE {
<pfps> $this $predicate ?value .
<pfps> FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } .
<pfps> }
<pfps> will return a result for any blank node that is an object of a triple with
<pfps> subject ?this and predicate $predicate only if no node in the graph is a
<pfps> SHACL instance of $class.
<pfps> So, even if pre-binding is fixed according to the SPARQL specification there
<pfps> will be no violations reported for
<pfps> ex:s1 a sh:Shape ;
<pfps> sh:scopeNode ex:Bob ;
<pfps> sh:property [ sh:predicate ex:child ; sh:class ex:Person ] .
<pfps> on the data graph
<pfps> ex:Bob ex:child _:Bill .
<pfps> ex:Susan a ex:Person .
pfps: use SPARQL spec to provide meaning to SHACL core components, they will not be correct
... could get SPARQL spec fixed, publish warning about changes to SPARQL for SHACL to work right.
... SHACL spec says something we can't use
<pfps> How do you disagree with this analysis?
AndyS: disagrees with this analysis. SPARQL engines seem to follow SHACL semantics. Treat blank nodes as constants. For some operations, have to transform SPARQL
<pfps> So the SPARQL specification is indeed saying something that SHACL can't use?
AndyS: did not disagree with the analysis
<pfps> It is not that the spec is unclear here. The spec is clear, unambiguous, and unproblematic.
Arnaud: implementations by convention do things that are consistent with SHACL, but there is risk in relying on this.
<pfps> It may be that implementations diverge from the SPARQL spec here.
<pfps> Note that this is not pre-binding.
Arnaud: fixing SPARQL probably isn't an option
<pfps> If the SPARQL community put together a consensus errata that clearly indicated a change to the SPARQL spec then I think that that would be adequate.
would require recharting the working group and could take a year
AndyS: parameterized queries was not addressed in SPARQL 1.1 due to limited time.
pfps: hard to make fixes to W3C recommendations. Community group could come together and agree that what we all do should be updated in the spec - should be sufficient to move forward
... right now SHACL depends on something that is counter to current SPARQL.
ericP: if Peter makes the case in writing, ericP will bring it forward
... eventually go to w3m
pfps: all the implementations agree with each other, but not the spec regarding what SHACL needs
<pfps> all the implementations that I know of, at least
Arnaud: there is no owner to address this for SPARQL. Could we treat this as an errata?
... has been an ongoing problem with W3C process
<AndyS> "RDF Tests Community Group"
pfps: RDF test community may be the right group to address this
<AndyS> which already exists.
AndyS: start with RDF test community, see where we get, then widen it as needed depending on what happens. Not the first bug in the spec.
<AndyS> SPARQL errata -- https://www.w3.org/2013/sparql-errata
Anarud: second option: say that SHACL is not based on SPARQL or uses or expects SPARQL to be used, in a specific way.
pfps: wg could do that but leaves open to complaints at succeeding stages. W3C management would possibly override the constraints. Not like SHACL needs and extension, it needs SPARQL to be changed to work as needed.
... this would essentially be forking the SPARQL spec
Who would define this? where would it be implemented? how would it be standardized?
jamsden PROPOSE: clarify meaning of EXISTS in the context of SHACL based on commun implementations and discuss the issue in SPARQL to motivate the clarification
hknublau: SHACL creates its own function to do the proper exists implementation.
pfps: this could introduce additional issues. A user function cannot take SPARQL syntax, but other arguments could be used
<AndyS> agree with that plan
Arnaud: could combine approaches, introducing new SHACL function if changes to SPARQL are not possible
<hknublau> should we write that down as a PROPOSAL?
Arnaud: results in deferring ISSUE-68
<Arnaud> PROPOSAL: we'll wait for the community to come up with an erratum for SPARQL we can use regarding EXISTS, if this doesn't pan out we will have to investigate defining our own extension instead
<pfps> 0
<hknublau> +1
<AndyS> +1
<kcoyle> 0
<ericP> 0
what does this dependency mean?
what are the implications for moving forward without resolving this.
<pfps> there is actually disagreement on other parts of EXISTS, some of which are related to SHACL's use of SPARQL
this this seems high risk and requires a proactive solution
AndyS: there is already awareness of the problem, issues recognized and that a change is required. This group could write up a proposed solution, but there may be ongoing progress already
Arnaud: put a deadline on assessing the progress and making a decision to seek another solution.
+1
RESOLUTION: we'll wait for the community to come up with an erratum for SPARQL we can use regarding EXISTS, if this doesn't pan out we will have to investigate defining our own extension instead
<Arnaud> ACTION: AndyS to work on an ERRATUM for EXISTs [recorded in http://www.w3.org/2016/06/23-shapes-minutes.html#action01]
<trackbot> Error finding 'AndyS'. You can review and register nicknames at <http://www.w3.org/2014/data-shapes/track/users>.
<AndyS> ACTION: aseaborne-tq to work on an ERRATUM for EXISTs [recorded in http://www.w3.org/2016/06/23-shapes-minutes.html#action02]
<trackbot> Created ACTION-38 - Work on an erratum for exists [on Andy Seaborne - due 2016-06-30].
<Zakim> pfps, you wanted to bring up the second half of this issue
<pfps> The current definition of pre-binding does not work at all. The current
<pfps> definition is, in effect, "whenever a SPARQL processor evaluates a pre-bound
<pfps> variable, it must use the given value." However, SPARQL only evaluates
<pfps> variables in specific circumstances.
<pfps> For example, in
<pfps> SELECT $this ($this AS ?subject) $predicate (?value AS ?object)
<pfps> WHERE {
<pfps> $this $predicate ?value .
<pfps> FILTER NOT EXISTS { ?value rdf:type/rdfs:subClassOf* $class } .
<pfps> }
<pfps> no evalution of $this, $predicate, or $class is done.
<pfps> This has the effect that sh:class will not return any validation results for
<pfps> any object in the data graph that is a SHACL instance of any node in the
<pfps> data graph, even if the counterintuitive effects of EXISTS here are fixed.
<pfps> However, if an object in the data graph is not a SHACL instance of any node,
<pfps> then sh:class will always return a violation result for it if the
<pfps> counterintuitive effects of EXISTS here are fixed.
<pfps> So, even if EXISTS is fixed in SPARQL there will be a violation reported for
<pfps> ex:s1 a sh:Shape ;
<pfps> sh:scopeNode ex:Bob ;
<pfps> sh:property [ sh:predicate ex:child ; sh:class ex:Person ] .
<pfps> on the data graph
<pfps> ex:Susan ex:child ex:Bill .
pfps: first half was problem with SPARQL, the second problem is pre-binding. SPARQL didn't define pre-binding, but implementations implement it in some cases. SHACL defined its own. Substitution was originally used, but had problems, now overriding the evaluation
doesn't evaluate when matching triples against the graph, results in example failures - match of triple with prebound data against the data graph
<pfps> I have brought up this precise problem in the past
pfps: we have to define what pre-binding has to do. Raises the EXISTS problem, that figure out something that works with the SPARQL specification - Peter has done this with a proposed fix, but won't be around to followup
... put a fake value at right after the where that supports blank nodes, put in the pre-bound values, then everything else works. Some implementations are probably actually doing this, but hard to know. Difficult to determin how implementations are doing pre-binding
<pfps> here is the draft of a message on blank nodes and EXISTS
<pfps> Here is a situation where the SPARQL 1.1 Query recommendation says something
<pfps> clearly, unambiguously, and unproblematically that is counterintuitive. At
<pfps> least some SPARQL implementations diverge from the SPARQL specification
<pfps> here, and it is entirely possible that all major SPARQL implementations do.
<pfps> Consider the query
<pfps> prefix ex: <http://www.example.org/>
<pfps> SELECT ?this WHERE {
<pfps> ?this ex:p ?value .
<pfps> FILTER NOT EXISTS { ?value ex:q ex:d } .
<pfps> }
<pfps> and the graph
<pfps> @prefix ex: <http://www.example.org/> .
<pfps> ex:b ex:p _:v .
<pfps> ex:c ex:q ex:d .
<pfps> According to the SPARQL 1.1 Query recommendation there will be no results
<pfps> from evaluating this query on this graph. This happens because the
<pfps> definition of EXISTS is via substitution, which ends up producing
<pfps> BCP( _:v ex:q ex:d )
<pfps> which then matches against the ex:c ex:q ex:d triple.
<ericP> rdf-tests issue for defn of EGCYSTS
<AndyS> ACTION: aseaborne-tq to email WG lists about the places where discussion on EXISTS is happening. [recorded in http://www.w3.org/2016/06/23-shapes-minutes.html#action03]
<trackbot> Created ACTION-39 - Email wg lists about the places where discussion on exists is happening. [on Andy Seaborne - due 2016-06-30].
<Arnaud> trackbot, end meeting