Re: sh:uniqueLang "1"^^xsd:boolean .

Hi!

> In a SPARQL filter, is “1”^^xsd:Boolean == true? Like
> “0001”^^xsd:integer == “1”^^xsd:integer.

yes (with lowercase B though -> xsd:boolean) :
http://sparql-playground.sib.swiss/?query=select%20%3Fperson%20%3Fpet%20where%20%7B%0A%20%20%7B%0A%20%20%20%20%3Fperson%20rdf:type%20dbo:Person%20.%0A%09%3Fperson%20tto:pet%20%3Fpet%20.%0A%20%20FILTER(%221%22%5E%5Exsd:boolean%20%3D%20true)%20.%0A%09%7D%0A%20%20UNION%0A%20%20%20%20%7B%0A%20%20%20%20%3Fperson%20rdf:type%20dbo:Person%20.%0A%09%3Fperson%20tto:pet%20%3Fpet%20.%0A%20%20FILTER(%220%22%5E%5Exsd:boolean%20%3D%20false)%20.%0A%09%7D%0A%20%20%20%20UNION%0A%20%20%20%20%7B%0A%20%20%20%20%3Fperson%20rdf:type%20dbo:Person%20.%0A%09%3Fperson%20tto:pet%20%3Fpet%20.%0A%20%20FILTER(%222%22%5E%5Exsd:boolean%20%3D%20true)%20.%0A%09%7D%0A%7D&output=html

> And are they isomorphic?

fwiw, the old RDF 1.0 REC had an example about the differences between 
value space and lexical space using xsd:boolean -> 
https://www.w3.org/TR/rdf-concepts/#section-Datatypes-intro
in the new RDF 1.1 specification there's 
https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal:
----
Literal term equality: Two literals are term-equal (the same RDF 
literal) if and only if the two lexical forms, the two datatype IRIs, 
and the two language tags (if any) compare equal, character by 
character. Thus, two literals can have the same value without being the 
same RDF term. For example:

       "1"^^xs:integer
       "01"^^xs:integer

denote the same value, but are not the same literal RDF terms and are 
not term-equal because their lexical form differs.
----

which would in theory also hold for:

       "1"^^xsd:boolean
       "true"^^xsd:boolean

as their lexical form  differs.. However, according to a footnote in 
https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal: "Invoking 
RDFterm-equal on two typed literals tests for equivalent values. "
-> Hence FILTER("0"^^xsd:boolean = false && "1"^^xsd:boolean = true && 
"1"^^xsd:boolean = "true"^^xsd:boolean) is true, while 
FILTER("2"^^xsd:boolean = true || "01"^^xsd:boolean = true) is not.

hth, simon


---
DDipl.-Ing. Simon Steyskal
Institute for Information Business, WU Vienna

www: http://www.steyskal.info/  twitter: @simonsteys

Am 2019-03-26 06:43, schrieb Håvard Ottestad:
> Hi,
> 
> Thank you for the good comments.
> 
> My problem is that I’m using RDF4J to parse the turtle file in the
> test, and when I do the following:
> 
> boolean uniqueLang = ((Literal) object).booleanValue();
> 
> It returns true. Because “1”^^xsd:Boolean means the same as
> writing true.
> 
> In a SPARQL filter, is “1”^^xsd:Boolean == true? Like
> “0001”^^xsd:integer == “1”^^xsd:integer.
> 
> And are they isomorphic?
> 
> Håvard
> 
> On 25 Mar 2019, at 23:31, Holger Knublauch <holger@topquadrant.com>
> wrote:
> 
>> On 26/03/2019 8:01 am, Andy Seaborne wrote:
>> 
>> Håvard - in what way does "1"^^xsd:boolean in uniqueLang-002 cause
>> specific problems? I can think of several! including the fact it
>> does really need the comment to be read.
>> 
>> On Mon, 25 Mar 2019 at 19:31, Håvard Ottestad
>> <hmottestad@gmail.com> wrote:
>> 
>> I don’t feel that SHACL gets to dictate syntax. Shapes can be
>> represented in any language, jsonld, rdfxml or turtle.
>> 
>> Agreed - any language for shapes.
>> 
>> Here is my spec reading: (not advocacy one way or the other, just
>> trying to dig into what the spec says)
>> 
>> true denotes the RDF term "true"^^xsd:boolean. false denotes the
>> RDF term "false"^^xsd:boolean.
>> 
>> so true  means the RDF term with lexical form "true" and datatype
>> xsd:boolean. That is conflating Turtle syntax here. It would look
>> different in JSON-LD.
>> 
>> My guess is that this true is used because it makes triple matching
>> without XSD-value interpretation work.
> 
> Yes, at the time it sounded like it makes implementations easier.
> Meanwhile, several people ran into this issue though, so maybe it
> wasn't the best decision to only support true. It arguably also wasn't
> the best decision by XSD to also support "1", but I guess when you
> pile technologies on top of each other then those downstream have to
> live with the consequences...
> 
> I am also keen to hear what the specific problem is though, and why a
> work-around is difficult. Adjusting the spec for a SHACL 1.1 would
> likely require an incompatible change, and it still feels like a minor
> scenario to me.
> 
> Holger
> 
>>> If “1”^^xsd:Boolean is the syntax equivalent to true; then
>>> it’s not up to the SHACL spec to specify which one is allowed.
>> 
>> It is not equivalent, not the same RDF term. Like
>> "+001"^^xsd:integer is a different RDF term from "1"^^xsd:integer.
>> 
>> Maybe that comment in uniqueLang-0002 has historical significance.
>> 
>> It seems to say the shape has no constraint.
>> 
>> Andy
>> 
>> Håvard
>> 
>> On 25 Mar 2019, at 20:24, Andy Seaborne
>> <andy.seaborne@topquadrant.com> wrote:
>> 
>> In the technical sense of SHACL? (It's legal Turtle)
>> 
>> The test has a comment in it:
>> 
>> # Note that the value above is "1"^^xsd:boolean, which is distinct
>> from "true"^^xsd:boolean.
>> # Only true is mentioned in the spec, meaning that "1" will not
>> activate the constraint
>> # and the constraint is being ignored.
>> 
>> which goes with the SHACL spec saying:
>> 
>> The property sh:uniqueLang can be set to true to specify that no
>> pair of value nodes [1] may use the same language tag.
>> 
>> and
>> 
>> sh:uniqueLang
>> true to activate this constraint.
>> 
>> it's not SHACL-true so this is not active.
>> 
>> I'm hesitant to say "invalid syntax" because it begs the question of
>> "which syntax?"
>> 
>> On Mon, 25 Mar 2019 at 18:36, Håvard Ottestad
>> <hmottestad@gmail.com> wrote:
>> 
>> Hi Andy,
>> 
>> Thanks for chiming in.
>> 
>> Do you feel that "1"^^xsd:boolean should be invalid syntax?
>> 
>> Håvard
>> 
>> On 25 Mar 2019, at 19:12, Andy Seaborne
>> <andy.seaborne@topquadrant.com> wrote:
>> 
>> On Mon, 25 Mar 2019 at 16:56, Håvard Ottestad
>> <hmottestad@gmail.com> wrote:
>> 
>> Hi,
>> 
>> I came across this little bugger in the test-suite and I would like
>> to propose to have it removed.
>> 
>> I’m talking about the uniqueLang-002 test which contains:
>> sh:uniqueLang "1"^^xsd:boolean .
>> 
>> The W3C RDF Turtle 1.1 spec mentions that there are only two legal
>> values for booleans (true or false):
>> https://www.w3.org/TR/turtle/#booleans
>> 
>> That is referring to the short forms true and false in syntax.
>> 
>> The Turtle spec ought really to say which RDF term it is short for;
>> the canonical form being the obvious choice.
>> (It is supposed to be the same as SPARQL sec 4.1.2 - seems the text
>> didn't get copied over.)
>> 
>> It links to the XML Schema definition of xsd:boolean where there are
>> four legal syntax values for boolean: true, false, 1, 0
>> 
>> It furthermore states that there are only two canonical values for
>> boolean: true, false
>> 
>> https://www.w3.org/TR/xmlschema-2/#boolean
>> 
>> The definition in the SHACL spec is as follows:
>> ###########
>> If $uniqueLang is true then for each non-empty language tag that is
>> used by at least two value nodes, there is a validation result.
>> 
>> ###########
>> 
>> My argument is that, unless the SHACL spec specifies the syntactical
>> representation of the boolean, then it is moot to have a test that
>> checks the syntax rather than the semantics.
>> 
>> I agree that  "true"^^xsd:boolean or true should be used in line
>> with the end of sec 1.2
>> 
>> Andy
>> 
>> Regards,
>> Håvard M. Ottestad
>> (developer of the RDF4J incremental SHACL engine)
> 
> 
> 
> Links:
> ------
> [1] https://www.w3.org/TR/shacl/#dfn-value-nodes

Received on Tuesday, 26 March 2019 06:42:46 UTC