RDF Data Shapes Working Group Teleconference

<Arnaud> hi Ted

<Arnaud> we are waiting for you :)

<scribe> scribenick:TallTed

Admin

<Arnaud> PROPOSED: Approve minutes of the 19 Oct 2016 Telecon: http://www.w3.org/2016/10/19-shapes-minutes.html

RESOLUTION: Approve minutes of the 19 Oct 2016 Telecon: http://www.w3.org/2016/10/19-shapes-minutes.html

<hknublau> With regards to summer time shift, I will suggest to move the future meetings forward, at least by 30 minutes because it would otherwise start at midnight for me.

Disposal of raised issues

<Arnaud> PROPOSED: Open ISSUE-192

<kcoyle> +1

+1

<Dimitris> +1

<hknublau> 0.5

<AndyS> +1

<ericP> +1

RESOLUTION: Open ISSUE-192

Clean up of no longer relevant issues

<Arnaud> PROPOSED: Close ISSUE-146 and ISSUE-190 as no longer relevant given the removal of sh:hasShape

<hknublau> +1

<Dimitris> +1

+1

<AndyS> +1

<kcoyle> +1

<ericP> +1

RESOLUTION: Close ISSUE-146 and ISSUE-190 as no longer relevant given the removal of sh:hasShape

<Dimitris> what about issue-158

ISSUE-140 - SHACL needs to support validation of individual nodes

<Arnaud> issue-140

<trackbot> issue-140 -- SHACL needs to support validation of individual nodes -- open

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

<ericP> https://ericprud.github.io/data-shapes/shacl/#MaxCountConstraintComponent

<hknublau> The tables look good to me.

<hknublau> We should just avoid the term "fail" because that's currently used for "failures" such as invalid recursion.

<Dimitris> maybe replace result with validates and pass/fail to yes/no

<ericP> propose 👍 👎

<hknublau> Assuming we do that, what else needs to happen to close ISSUE-140?

TallTed: this appears to be confirmation that SHACL does support validation of individual nodes, so once complete, ISSUE-140 is done

ISSUE-158 -- ill-typed literals do not always trigger a validation result

<Arnaud> issue-158

<trackbot> issue-158 -- ill-typed literals do not always trigger a validation result -- open

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

<Dimitris> ex:i1 ex:p "c"^^xsd:integer

Dimitris: proposes we just say nothing

Arnaud: expects it will be implementation dependent

ericP: errors will likely happen with maxvalue/minvalue ... and testsuite includes these issues

hknublau: also in favor of not handling this. could be handled by extensions, custom constraint components.
... one major concern is weight of process.

ericP: leaving this out doesn't seem to lessen our work. evaluating numeric constraints seems to require numeric values...

hknublau: this seems like an extra test. evaluating a letter value against a numeric restriction will already produce some error; no need to check first that the value being compared is a number.

Dimitris: [echoes Holger]

kcoyle: don't see how we can *not* do this. could write SHACL validations for everything, to check this type of thing, but we should say what is supposed to happen if the data graph itself has problems such as "string"^^xsd:int
... we can't just rely on SPARQL, particularly for people who aren't using SPARQL

Dimitris: suppose we support xsd:int and xsd:integer, and then I create my own ex:int and ex:integer, what is SHACL to do?

<ericP> i don't see any performance impact given that SPARQL/XML Schema impls already have a prescribed behavior

<AndyS> Example: SELECT (COALESCE ("555"^^<http://www.w3.org/2001/XMLSchema#byte>+0, "invalid") AS ?X) {}

AndyS: what SPARQL can check depends on the implementation. it can be messy to handle even simple things, it's worse when you get into custom.
... if I have ^^fubar and you don't, and I pass you a shape def using it, what happens?

<Zakim> ericP, you wanted to question expense

AndyS: building SPARQL operations can cover a small set of datatypes, but not all xsd, and certainly not all custom

ericP: wonder what we'd be enforcing? SPARQL has prescribed behaviors for comparisons... facets have to be lexically valid though not necessarily canonical form...
... seems like this is already done, if using a reasonable engine. unreasonable engines are likely to give strange responses anyway.
... how many digits in "a1"?

Arnaud: let's consider the original example in the issue... ` "c"^^xsd:integer `

ericP: SPARQL would ignore that until trying to operate on it

TallTed: basic confirmation that typed literals conform to the (basic, xsd or the like) type they claim to be seems vital
... it could be made switchable, if performance is hugely impacted in spaces where this level of validation is deemed unnecessary

kcoyle: starting by saying "data must be valid" dodges the whole concept of data validation...

<Dimitris> ex:i1 ex:p "c"^^xsd:integer

[having triples with predicates which aren't part of the shape, with invalidly typed literals, seems ok] ?

<Zakim> ericP, you wanted to describe the SPARQL Operator Mapping

ericP: many operations (numeric comparisons, etc.) already have defined results. it's only the question of "this must be an integer" that remains.

<ericP> SPARQL Operator Mapping

<kcoyle> what happens with: dct:title must be a literal ? dct:subject must be an IRI ?

ericP: for SPARQL, we said "here are the operators and datatypes SPARQL handles" and defined what happens with those, and left other things to be implementation specific
... delivers both "here's what you can count on" and extensibility

<Dimitris> how about a strawpoll with a) validate well-formed literals for all xsd datatypes b) do not check for ill-formed literals

<Dimitris> (when a sh:datatype constraint is defined)

<kcoyle> What's an "ill-formed literal"?

<Dimitris> "c"^^xsd:integer

<Arnaud> STRAWPOLL: a) leave this undefined (quality of the implementation), b) require implementation to check well-formedness for built-in datatypes, c) add a new constraint to check well-formedness of literals

<kcoyle> thanks

<ericP> a:-.9 b:.5 c:0

a) -0.9 b) +0.5 c) +1

<kcoyle> a) -1 b) +1 c) 0

<Labra> a) -0.9 b) +1 c) 0

<Dimitris> a) -0 (should say something) b) +1 c) +1

<Dimitris> we should define build-in

<Dimitris> and we should specify we refer to sh:datatype only here (or not)

<Arnaud> https://www.w3.org/TR/xmlschema11-2/#built-in-datatypes

<hknublau> Someone needs to come up with a formally acceptable proposal for the new definition of sh:datatype. Only then we can vote.

<Arnaud> PROPOSED: Close ISSUE-158, requiring implementations to check well-formedness for built-in datatypes covered in SPARQL 1.1 Query

<ericP> +1

<Labra> +1

<kcoyle> +1

<hknublau> ... for sh:datatype

<Arnaud> PROPOSED: Close ISSUE-158, requiring implementations to check well-formedness for built-in datatypes covered in SPARQL 1.1 Query for sh:datatype

<ericP> +1

+1 better than not at all

<Labra> +1

<Dimitris> +1 although it can get slow

<kcoyle> +1

<hknublau> 0

RESOLUTION: Close ISSUE-158, requiring implementations to check well-formedness for built-in datatypes covered in SPARQL 1.1 Query for sh:datatype

<Arnaud> trackbot, end meeting