Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
onthebreeze opened this issue May 27, 2021 · 11 comments
Open

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

onthebreeze opened this issue May 27, 2021 · 11 comments
Assignees

Comments

@onthebreeze
Copy link
Contributor

onthebreeze commented May 27, 2021

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
Copy link
Contributor Author

@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
Copy link
Contributor

Fak3 commented May 28, 2021

@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
Copy link
Contributor Author

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
Copy link
Contributor

Fak3 commented May 29, 2021

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

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
Copy link

AP-G commented May 31, 2021

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
Copy link
Contributor Author

onthebreeze commented May 31, 2021

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
Copy link

AP-G commented May 31, 2021

You mean NOT to embed mysterious rules, right?

@onthebreeze
Copy link
Contributor Author

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

@Fak3
Copy link
Contributor

Fak3 commented Jul 14, 2021

This seems to be a duplicate of #47

@VladimirAlexiev
Copy link

@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
Copy link

VladimirAlexiev commented Feb 1, 2022

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants