Multivalued or union sh:dataType

[VladimirAlexiev]

Some literal (attribute) props naturally admit a variety of datatypes, eg

• dc:date, dct:created etc can be xsd:date, xsd:dateTime, xsd:dateTimeStamp
• s:name can be xsd:string, rdf:langString
• ex:age can be byte, int, integer, and their nonNegative variants (Inspired by Improve validation rules for XSD integer datatypes #142)
• sh:order can be integer or decimal (SHACL vocabulary is inconsistent #125)

SHACL can express this with sh:or property shapes, but it gets tedious.
Can we allow multiple values of sh:dataType?

Alternatively, we could think of some synthetic "union datatypes", eg

• sh:dateOrDateTimeStamp
• sh:stringOrLangString (rdf:PlainLiteral means the same)
• sh:natural, sh:nonNegativeNatural, etc

We actually have the first two in Ontotext SOML (GraphQL), which in SHACL is expanded to sh:or

[HolgerKnublauch]

The union datatype approach works quite well and comes out of the box in the dash namespace

https://datashapes.org/dash.html#union-datatypes

Adding multiple sh:datatypes would be inconsistent with how the rest of SHACL is working - no other constraint component takes multiple values of the same property.

I agree however that processing this through sh:or is not elegant. The old WG had considered something like sh:datatypeIn which would take an enumeration but rejected this in order to keep the language smaller.

[afs]

A union datatype has consequences for data exchange though. The import and use of such data must now consider all possibilities or be "by value".

Adding as a library, rather than changing SHACL-core is better. Then a system can publish which libraries it is using, which is a contract it can adhere to even if it is not using all features at one point in time.

In other words - shapes files declare feature sets, whether by imports or a new, specific property.

[ajnelson-nist]

Is it possible to consider datatype hierarchy to address some of the concerns in this thread and related issues?

For instance, quoting XSD 1.1:

The dateTimeStamp datatype is ·derived· from dateTime by giving the value required to its explicitTimezone facet.

Specifically, because of the term "derived," should a DatatypeConstraint requiring xsd:dateTime accept xsd:dateTimeStamp, without the need to resort to sh:or?

I'm unaware of history on this topic, and would welcome any pointers to prior discussion on or not on this tracker.

[HolgerKnublauch]

One idea (not fleshed out) to improve the syntax of union constraints would be to introduce a new kind of NodeShapes for which multiple constraints are interpreted as "OR" instead of "AND". For example:

ex:SomeClass-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:or [
        sh:datatype xsd:string ;
        sh:datatype rdf:langString ;
    ]

Above I am reusing sh:or - this time allowing something else than an rdf:List - but we could also introduce a new property. The value of sh:or above would be a shape with OR semantics. The same could be applied to xone.

[tfrancart]

May I even suggest an even more simplified encoding for unions, in which one would simply repeat the sh:datatype triple:

ex:SomeClass-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:datatype xsd:string, rdf:langString ;

My practice shown that unions of constraints are most of the time applied on the same constraints (e.g. an OR of sh:datatype, or an OR of sh:class, etc.). So maybe a flag on the shapes graph level or on the node shape level could say "treat values of the same constraint on a single shape as a UNION", so that the above encoding would have the same semantic as the corresponding sh:or.

[HolgerKnublauch]

This would be a breaking change, unfortunately. And it gets worse for cases like union sh:class constraints, because the original intention MAY actually have been intersection semantics so we cannot just change that to union with the very same syntax.

[tfrancart]

This would be a breaking change, unfortunately.

So as to not break the existing semantic I was thinking about another flag somewhere that would trigger this "interpret-multiple-values-as-unions" semantic:

ex:MyShapes a owl:Ontology ;
  # new flag ?
  sh:multipleConstraintValuesAsUnions true .


ex:SomeClass-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:datatype xsd:string, rdf:langString ;

(this is all syntactic sugar)

[afs]

Being RDF,

ex:SomeClass-someProperty sh:datatype xsd:string .
ex:SomeClass-someProperty sh:datatype rdf:langString .

means both apply, which is intersection.

How a list is processed can be a decision of the SHACL spec.

[tfrancart]

means both apply, which is intersection.

I see what you mean, because sh:datatype implicitely means "datatype is equal to".

[HolgerKnublauch]

I notice that this relates to #311 : It would be quite elegant if we could allow rdf:Lists as values for sh:datatype, and interpret those as union.

ex:SomeClass-someProperty
    a sh:PropertyShape ;
    sh:path ex:someProperty ;
    sh:datatype ( xsd:string rdf:langString ) ;
.

This should work without breaking things because until now the values of sh:datatype needed to be URIs. So we can allow blank nodes, and those could be either lists or, assuming that there is a node expression type for rdf:Lists, we could also allow any node expression here. So if we elect to go with #311 we are solving this ticket here for free. However, just doing rdf:Lists would also be a good solution.