XSD data types instead of xs:string for value type

[mhrimaz]

I was wondering why, for value, the type is always xs:string and we use 'valueType' with DataTypeDefXsd/* as value?

If everything is a string, then how do I query over property values? Either I should manually convert the types or infer the types automatically. But in the provided ontology, DataTypeDefXsd does not contain any linking to the actual XSD type.

Example Double property serializaiotion

@prefix aas: <https://admin-shell.io/aas/3/0/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .

<something_48c66017> rdf:type aas:Submodel ;
    <https://admin-shell.io/aas/3/0/Identifiable/id> "something_48c66017"^^xs:string ;
    <https://admin-shell.io/aas/3/0/Submodel/submodelElements> [
        rdf:type aas:Property ;
        <https://admin-shell.io/aas/3/0/Referable/idShort> "something3fdd3eb4"^^xs:string ;
        <https://admin-shell.io/aas/3/0/Property/valueType> <https://admin-shell.io/aas/3/0/DataTypeDefXsd/Double> ;
        <https://admin-shell.io/aas/3/0/Property/value> "1234.01234"^^xs:string ;
    ] ;
.

One alternative approach: instead of <https://admin-shell.io/aas/3/0/Property/value> "1234.01234"^^xs:string ; we use <https://admin-shell.io/aas/3/0/Property/value> "1234.01234"^^xs:double; and remove <https://admin-shell.io/aas/3/0/Property/valueType> <https://admin-shell.io/aas/3/0/DataTypeDefXsd/Double> ; because it is redundant.

@prefix aas: <https://admin-shell.io/aas/3/0/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xs: <http://www.w3.org/2001/XMLSchema#> .

<something_48c66017> rdf:type aas:Submodel ;
    <https://admin-shell.io/aas/3/0/Identifiable/id> "something_48c66017"^^xs:string ;
    <https://admin-shell.io/aas/3/0/Submodel/submodelElements> [
        rdf:type aas:Property ;
        <https://admin-shell.io/aas/3/0/Referable/idShort> "something3fdd3eb4"^^xs:string ;
        <https://admin-shell.io/aas/3/0/Property/value> "1234.01234"^^xs:double;
    ] ;
.

[mhrimaz]

As discussed in IDTA Open Hours, the reason was because of more flexibility, avoiding information loss in round trip conversions, and stay consistent with XML/JSON mapping.

[mhrimaz]

@sebbader Regarding the datatypes, as it was mentioned, the string type chosen for all types. However, in DataSpecificationIec61360 the level type has boolean datatype: https://github.com/admin-shell-io/aas-specs/blob/bb6747a17ca51d3a08bcf03b2fc927671ab3433b/schemas/rdf/examples/generated/DataSpecificationIec61360/maximal.ttl#L57-L63 Is this an inconsistency or there is a reason for it?

[mhrimaz]

Furthermore in Blob we are also using xsd:base64Binary https://github.com/admin-shell-io/aas-specs/blob/13b904f5b546aade0459b40e3b30953e6af50e0a/schemas/rdf/examples/generated/Blob/maximal.ttl#L76

[mhrimaz]

@kenwenzel Do you have any idea regarding the usage of datatypes and also the inconsistencies?

[mristin]

@mhrimaz just a remark related to these changes: please make sure that you patch aas-core-codegen, not the schemas directly.

[VladimirAlexiev]

I also agree that this is not idiomatic RDF and has many problems.

• Semantic repositories index number and date literals specially, so that you can make fast comparisons and range searches.
• If you keep the datatype in a separate field, that functionality is lost
• For modern XSD dateTime stamps (year 0000..9999) without timezone, that's not a big loss since lexicographic string sort does the same
• But for numbers that is a big loss
• You cannot even check equality of values, unless they are normalized. "3.14"^^xsd:decimal = "03.140"^^xsd:decimal but that is not true of strings

more flexibility

More flexibility at the loss of defined functionality is no win at all.

• Why do we use strings? It would be more flexible to break them down into constituent characters and store them in individual nodes: then I can point to an individual character, right?
• The reason is that everyone would hate such design decision: it's impractical

Why no XML attributes?

I find the arguments here weak.

• XML defined XSD Datatypes and xml:lang maybe 20 years ago. There's no good argument why these standards should not be followed
• Ok: do not use custom XML attributes if you suspect those will need to be expanded
• But do use attributes that have been standardized 20 years ago!

avoiding information loss in round trip conversions, stay consistent with XML/JSON mapping

There is no information loss!

• In XML just use the predefined attributes
• In JSONLD the fields are predefined (@value, @type) but can be renamed in the context

in DataSpecificationIec61360 the level type has boolean datatype in Blob we are also using xsd:base64Binary

The reason is that these props are predefined (fixed) in the spec. But such rational use is not permitted for props to be defined in a particular AAS application ;-)

[VladimirAlexiev]

@mristin @mhrimaz @sebbader @kenwenzel @wiresio

aas:DataTypeDefXsd defines its own URLs so it disregards the XSD Datatypes standard, which was defined:

• initially 24y ago: https://www.w3.org/TR/2000/WD-xmlschema-2-20000225/
• in its final form 20 years ago: https://www.w3.org/TR/xmlschema-2/

I think it is a bad practice to disregard age-tested standards, especially those that are the basis of typed values in both XML and RDF.

Eg If we take this as example: https://github.com/admin-shell-io/aas-specs/blob/2ab08f92bdd1d44edc1cfee52552fe5429d2178e/schemas/rdf/examples/generated/Property/OverValueExamples/Any_URI/relative_path_without_scheme.ttl#L9-L14

it should be changed to the following (skipping ^^xs:string, which is superfluous)

    <https://admin-shell.io/aas/3/0/Submodel/submodelElements> [
        rdf:type aas:Property ;
        <https://admin-shell.io/aas/3/0/Referable/idShort> "something3fdd3eb4";
        <https://admin-shell.io/aas/3/0/Property/value> "path/to/somewhere"^^xs:anyURI;
    ] ;

Can you point me to some JSON examples? Then we can figure out how to enrich the context to convert the JSON to this desired RDF representation.

[BirgitBoss]

..