traceability-vocab

traceability-vocab copied to clipboard

In a JSONLD context one can and should declare the datatypes of props, so that a JSON payload string is mapped to the appropriate datatype.

• (This is unlike the expected range of an object property, which cannot be declared, because the type of all such props is @is)

This is especially important for literals that don't have native JSON type (xsd:date, xsd:dateTime). It's also important for numbers, which are subject to rounding/mangling in JSON. Eg this JSONLD payload:

{"@context":{
   "xsd":"http://www.w3.org/2001/XMLSchema#",
   "foo": {"@type":"xsd:boolean","@id":"https://example.org/foo"},
   "foo1":{"@type":"xsd:boolean","@id":"https://example.org/foo1"},
   "bar": {"@type":"xsd:decimal","@id":"https://example.org/bar"},
   "bar1":{"@type":"xsd:decimal","@id":"https://example.org/bar1"},
   "baz": {"@type":"xsd:integer","@id":"https://example.org/baz"}
  },
  "foo":"true","foo1":true,"bar":"12.345678901234567890","bar1":12.345678901234567890,"baz":123456789012345678901234567890}

is converted to this ntriples at https://json-ld.org/playground/. Notice the rounding of bar1, and the syntactically incorrect value of baz:

_:b0 <https://example.org/bar1> "1.234567890123457E1"^^<http://www.w3.org/2001/XMLSchema#decimal> .
_:b0 <https://example.org/bar> "12.345678901234567890"^^<http://www.w3.org/2001/XMLSchema#decimal> .
_:b0 <https://example.org/baz> "1.234567890123457E29"^^<http://www.w3.org/2001/XMLSchema#integer> .
_:b0 <https://example.org/foo1> "true"^^<http://www.w3.org/2001/XMLSchema#boolean> .
_:b0 <https://example.org/foo> "true"^^<http://www.w3.org/2001/XMLSchema#boolean> .

It's less important for booleans because the values are not subject to rounding.

Examples:

1. credentials/USMCACertificationOfOrigin.yml:

  importerUnknown:
    title: Importer Unknown
    description: >-
      If the identity of the importer is unknown, or there are various
      importers, please check the appropriate box.
    type: boolean
    $linkedData:
      term: importerUnknown
      '@id': https://w3id.org/traceability#importerUnknown

could add

      '@type': 'xsd:boolean'

2. common/IATAAirWaybill.yml:

  executedOn:
    title: Executed on (Date)
    description: >-
      The date of execution of the air waybill shall be inserted in the sequence
      of day, month and year. The month shall be expressed alphabetically,
      either abbreviated or in full. Box 32A.
    type: string
    $linkedData:
      term: executedOn
      '@id': https://w3id.org/traceability#executionTime
      '@type': http://www.w3.org/2001/XMLSchema#dateTime

already has @type, but maybe the JSON type should be changed from string to something better?

3. common/Transport.yml:

  plannedDepartureDate:
    title: Planned Departure Date
    description: The planned date of departure.
    type: string
    $linkedData:
      term: plannedDepartureDate
      '@id': https://schema.org/Date

Must change to this ( I assume JSON Schema has type dateTime)

    type: dateTime 
    $linkedData:
       term: plannedDepartureDate
       '@id': traceability:plannedDepartureDate
       '@type': xsd:dateTime

We need a way to visualize this, and break it down into smaller chunks so it can be addressed.

The action to take on this issue would be to write a script to produce the numbers for this issue.

Proposal: introduce a chart similar to undefinedTerms which we can use to track progress on missing datatypes.

This ticket needs to be broken into smaller issues. Somehow.

Assigned myself to produce an example of a relevant schema, so we can get agreement of what a proper, fully datatyped schema should look like.

Very similar to https://github.com/w3c-ccg/traceability-vocab/issues/573

At its most basic, this could be just a couple of counters like this: