Re: sh:equal, sh:hasValue, sh:in: identity (sameTerm) vs equality

Yes, the interpretation should be sameTerm, and the prose could 
sometimes be clearer on that. Blame the editor on the latter. 
Unfortunately there is no SHACL 1.1 WG to fix formal definitions that 
could lead to further controversies. Meanwhile, I guess if implementors 
are not sure what to do, they look at other implementations. 
Technically, one reason for doing sameTerm semantics was performance.

One way to evolve your use cases could be to introduce an optional 
boolean flag such as sh:matchEquality true which could be a second 
argument to sh:equals, sh:hasValue and sh:in. Another way would be (as 
you say) to introduce completely new constraint components.

Maybe this should become a GitHub issue so that a SHACL 1.1 WG can pick 
this up?

Holger

PS: Given the increasing interest in SHACL, I guess once a 1.1 WG is 
created, many people will suggest new features and improvements. All it 
needs is a couple of dedicated individuals to drive the process and 
build a functioning WG.


On 2022-05-17 6:05 pm, Vladimir Alexiev wrote:
> It appears that sh:equal, sh:hasValue, sh:in compare values using 
> identity (sameTerm) rather than equality (=).
> Which is ok for many cases but not all.
>
> In particular for literals: sameTerm uses the lexical space, whereas 
> equality uses the value space.
> The following are true for equality but not for identity:
>
>   * "0"^^xsd:boolean = "false"^^xsd:boolean
>   * "1"^^xsd:integer = "01"^^xsd:integer
>   * "0.0"^^xsd:float = "0.00"^^xsd:float
>
> Which means that it's unnecessarily hard or even impossible to express 
> rules like this in standard SHACL:
>
>   * vatInVies should not be false (boolean). This can be expressed
>     using the two lexical representations of "false".
>   * installedCapacity should not be zero (float). There are infinitely
>     many lexical representations of zero (even crazy ones like
>     "0.0000000000001"^^xsd:float)
>   * installedCapacity of an outage record should be equal to
>     installedCapacity in the master power plant record (float)
>
> Looking at the 3 constraint components in the spec:
>
>   * *sh:equal*: https://www.w3.org/TR/shacl/#EqualsConstraintComponent
>     says "is equal" but then "exist as a value of the property $equals"
>   * *sh:hasValue*:
>     https://www.w3.org/TR/shacl/#HasValueConstraintComponent says "is
>     equal" but then "not among the value nodes", which I find ambiguous
>   * *sh:in*: https://www.w3.org/TR/shacl/#InConstraintComponent
>     says  "is a member" and then explicitly "matching of literals
>     needs to be exact"
>
> I propose to change:
>
>   * "is equal" to "*is identical*" for the first two, and add the same
>     note "matching of literals needs to be exact".
>   * Add "is an *identical *member" for the third one.
>
> Furthermore, I propose to add 3 new constraint components that use 
> equality rather than identity.
> I cannot come up with better names, so suggestions are welcome. I 
> guess it's impossible to add them to *sh:* so maybe add them to *dash:* ?
>
>   * *dash:equalEQ*
>   * *dash:hasValueEQ*
>   * *dash:inEQ*
>
> -- 
> Vladimir Alexiev, PhD, PMP
> Chief Data Architect
> Sirma AI, trading as Ontotext: https://www.ontotext.com, LinkedIn 
> <https://www.linkedin.com/company-beta/208070>,Twitter 
> <https://twitter.com/ontotext>,Rate GraphDB 
> <http://www.capterra.com/database-management-software/reviews/157533/Graph%20DB/Ontotext/new>
> Email: vladimir.alexiev@ontotext.com, skype:valexiev1
> Mobile: +359 888 568 132, SMS: 359888568132@sms.mtel.net
> Calendar: 
> https://www.google.com/calendar/embed?src=vladimir.alexiev@ontotext.com
> Publications and CV: https://github.com/VladimirAlexiev/my