Data types need to be more explicit in the JSON-LD

[onthebreeze]

From slack thread Andreas Pelekies:

Exporting: In section 2.3.4 the handling of CCTS versus JSON data types is described. For instance a CCTS<> shall be mapped to JSON string with format qualifier "datetime". If I take a look for instance at the property "borderCrossingDateTime" from TransportMovement in the vocab only a

  "@id": "xsd:string"
}

is defined. The format is missing. When importing to StarUML I think you do "the magic" by looking at the ending of the name or the cefact metadata, right? I think this does not match section 2.3.4 as a "Newby" web developer will probably not read this guideline before using the vocab. So it would be better to add the format information. In addition the "Core data types" are missing completely in the vocab and you implicitely add them in the import routine. Wouldn't it make more sense to add them in the vocab export as well and then attach the rangeIncludes directly to the Core Types?

[onthebreeze]

@Fak3 @kshychko

I think andreas is right that we have some "magic" code in our starUML importer that sets data types. And I think he's right that there should be something more explicit in the JSON-LD vocab that drives this. In the example Andreas gives, we know that the CDT for borderCrossingDateTime is DateTime and so we should be able to set a corresponding xsd:dateTime type instead of xsd:string in the JSON-LD vocabulary?

[Fak3]

@kshychko can you make the vocab generator to set range xsd:dateTime to any property ending with "DateTime"? And "xsd:date" for properties ending with "Date"

[onthebreeze]

And, in general, the right xsd type for the relevant cdt ? For example xsd:decimal xsd:Boolean xsd:QName. How about we suggest a mapping from CDTs to XSD types, put that in the NDR document, and then implement it ?

[Fak3]

Perhaps we can use column M "Representation Term" to guess xsd type:

Amount -> xsd:decimal
Binary Object -> xsd:anyURI
Code -> (class of relevant UNCL code)
Date -> xsd:date
Date Time -> xsd:dateTime
Identifier -> xsd:anyURI
Indicator -> xsd:boolean
Measure -> xsd:double
Numeric -> xsd:integer
Percent -> xsd:decimal
Quantity -> xsd:nonNegativeInteger
Rate -> xsd:decimal (???)
Text -> xsd:string
Value -> seems to be deprecated? use xsd:string

everything else is xsd:string

[AP-G]

Hi all. If I understand your proposal correct, I do not agree to it. It should not be defined how to import a JSON-LD to UML and change the data type name based on naming. This will not be intuitive for any implementers outside this group. Instead a rule should be set up for the creation of the JSON-LD. I took a look at the official GS1 Vocab extension for schema.org. There it is solved using e.g. this:

"rdfs:range": {
                "@id": "xsd:dateTime"
            },

So it would follow an already existing way of schema.org and it would be intuitive for new developers. The transformation from JSON-LD to JSON schema or UML to JSON schema would be clearly defined as well.

[onthebreeze]

Hi Andreas - I think we are actually agreeing. This ticket has nothing to do with UML. It's about the NDR to create better json-ld WITH data types. So we are proposing to fix the source (JSON-LD) and NOT embed mysterious rules in some UML importer

[AP-G]

You mean NOT to embed mysterious rules, right?

[onthebreeze]

Yes, sorry - I fixed the comment to add that critical "NOT" ;)

[Fak3]

This seems to be a duplicate of #47

[VladimirAlexiev]

@AP-G The example you give (rdfs:range) is part of an ontology not a JSON-LD context. For example:

• context: {"borderCrossingDateTime": {"@type": "xsd:dateTime"}}
• ontology: {"borderCrossingDateTime": {"rdfs:range": "xsd:dateTime"}} (or schema:rangeIncludes)

The context allows JSONLD instance data to say {"borderCrossingDateTime":"2021-12-21"}
which will then be converted to RDF like borderCrossingDateTime "2021-12-21"^^xsd:dateTime (expressed in turtle).

Someone could still provide an explicit (and even wrong) datatype, eg
{"borderCrossingDateTime": {value: "2021-12-21", "@type":"ex:foo"}}
and JSONLD will comply and use that datatype.

[VladimirAlexiev]

@Fak3 thanks for the mapping table! Questions:

Identifier -> xsd:anyURI

Disagree, see uncefact/spec-jsonld#48, uncefact/spec-jsonld#49

Binary Object -> xsd:anyURI

1. Are you sure? There's also hexBinary that allows embedding the file
2. How to indicate the MIME type?
3. See also BinaryObject vs BinaryFile uncefact/spec-jsonld#53

Amount -> xsd:decimal
Measure -> xsd:double
Numeric -> xsd:integer
Percent -> xsd:decimal
Quantity -> xsd:nonNegativeInteger
Rate -> xsd:decimal (???)

Better pick and standardize your numeric types very carefully (uncefact/spec-jsonld#46) because w3c/json-ld-syntax#387.
We don't need a big variety of them, integer and decimal is enough IMHO (nonNegative variants are also ok)