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

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.

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 <https://www.w3.org/TR/shacl/#dfn-value-nodes> 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)
>>>
>>
>>