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.