timestamp format string or complex object?

[matgnt]

Might be jsonld related, the timestamp field sometimes is a string (EDC implementation) and sometimes an object with @type and @value (here in the spec)

We need to find out if this is really jsonld valid to have both and decide whether we want to 'profile' it to be one or the other way.

What are the different options we have and how to fix this in the spec?

[sebbader-sap]

Currently the following options are possible:

1. "simple string option":

"dspace:timestamp":"2023-01-01T01:00:00Z"

Problem: Value is not typed, not self-described. Not how JSON-LD should do it (I mean, that's why we went for JSON-LD and not plain JSON, right? :-))

2. XSD Literal:

"dspace:timestamp": {
      "@value": "2023-01-01T01:00:00Z",
      "@type": "xsd:dateTime"
    }

Problem: Requires an enabled parser (as any real JSON-LD parser can do), time zone might be missed

3. XSD Literal but with Time Zone required:

"dspace:timestamp": {
      "@value": "2023-01-01T01:00:00Z",
      "@type": "xsd:dateTimeStamp"
    }

See: https://www.w3.org/TR/xmlschema11-2/#dateTimeStamp
Problem: Same as 2. just that the time zone is included for sure. Furthermore, dateTimeStamp is part of XML Schema 1.1, which is not necessarily known to all implementations (different to XML Schema 1.0 with dateTime)

4. OWL Time (as demanded by DCAT):
   
   See: https://www.w3.org/TR/owl-time/#time:Instant
   Problem: complete overkill

5. others?

My preference is option 2 (as a Literal with xsd:dateTime) as it's the best compromise of expressivity and added attributes. If the time zone is not stated, UTC is meant.

[mkollenstart]

Option 5 can be a combination of 1 and 2 by using JSON-LD Type Coercion. Which allows setting the type in the JSON-LD context.

The result would look like:

{
  "@context": {
    "dspace": "https://w3id.org/dspace/v0.8/",
    ...
    "dspace:timestamp": {
       "@type": "xsd:dateTime"
    }
  }
  ...
  "dspace:timestamp":"2023-01-01T01:00:00Z"
  ...
}

This would lead to a larger context document but results in much improved readability of the JSON documents. Since the context document can easily be cached, using such a larger context would be my preference.

After a quick initial look this can be used for dct:issued, dct:modified, dct:created, dspace:timestamp (all xsd:dateTime); dcat:byteSize, dcat:spatialResolutionInMeters (xsd:decimal); dcat:temporalResolution (xsd:duration)

Similarily, this idea can also be used for identifiers with the possibility to replace:

{
   ...
   "odrl:assigner": {
      "@id": "http://example.com/Provider"
   }
   ...
}

with

{
  "@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/",
    ...
    "odrl:assigner": {
       "@type": "@id"
    }
  }
  ...
  "odrl:assigner":"http://example.com/Provider"
  ...
}

without losing the typing information from JSON-LD

[sebbader-sap]

"@context": {
    "dspace": "https://w3id.org/dspace/v0.8/",
    ...
    "dspace:timestamp": {
       "@type": "xsd:dateTime"
    }
  }

looks very good!

[sebbader-sap]

"@context": {
    "odrl": "http://www.w3.org/ns/odrl/2/",
    ...
    "odrl:assigner": {
       "@type": "@id"
    }
  }

But this one I hardly understand :-). Need to read the spec more in detail. Will come back soon.

[matgnt]

Agreed in the meeting:

• add type to the context as proposed by @mkollenstart
• use xsd:dateTime (reason: better support in different versions of xml schema...)
• if timezone is NOT given, use UTC as a fallback / default (stadard in xml schema...)

Open @mkollenstart

• add to profile definition: @value types have to use simplified version?? how about compaction?
• needs verification with different language libraries first

In case both options are required, we need to find a way (Unions?) to allow both in json schema. @sebbader-sap

[matgnt]

I've done some tests with python pyld (2.0.3) and here the timestamp is always in simplified (pure string) after compacting the document.
Here are a few test steps I did:
https://github.com/boschresearch/py-cx-ids/blob/68c42267dd18ad0bd4042070cdec188f3a76469e/pycxids/jsonld/test_jsonld.py#L25

[mkollenstart]

If done some testing based on the jsonld Javascript package (jsonld 8.2.0 also used in the JSON-LD Playground). As well as the Java Titanium library. Both provide the same behaviour.

The context I'm currently using is:

{
  "odrl": "http://www.w3.org/ns/odrl/2/",
  "xsd": "http://www.w3.org/2001/XMLSchema#",
  "cred": "https://www.w3.org/2018/credentials#",
  "sec": "https://w3id.org/security#",
  "foaf": "http://xmlns.com/foaf/0.1/",
  "cc": "http://creativecommons.org/ns#",
  "dct": "http://purl.org/dc/terms/",
  "dcat": "http://www.w3.org/ns/dcat#",
  "dspace": "https://w3id.org/dspace/v0.8/",
  "dspace:timestamp": { "@type": "xsd:dateTime" },
  "dspace:transportType": { "@type": "@id" },
  "dct:title": { "@language": "en" },
  "dct:issued": { "@type": "xsd:dateTime" },
  "dct:modified": { "@type": "xsd:dateTime" },
  "dct:created": { "@type": "xsd:dateTime" },
  "dcat:byteSize": { "@type": "xsd:decimal" },
  "dcat:endpointURL": { "@type": "xsd:anyURI" },
  "dspace:agreementId": { "@type": "@id" },
  "dspace:dataset": { "@type": "@id" },
  "dct:publisher": { "@type": "@id" },
  "dct:format": { "@type": "@id" },
  "dct:type": { "@type": "@id" },
  "odrl:assigner": { "@type": "@id" },
  "odrl:assignee": { "@type": "@id" },
  "odrl:action": { "@type": "@id" },
  "odrl:target": { "@type": "@id" },
  "odrl:leftOperand": { "@type": "@id" },
  "odrl:operator": { "@type": "@id" },
  "odrl:rightOperandReference": { "@type": "@id" },
  "odrl:profile": { "@type": "@id" },
  "dspace:reason": { "@container": "@set" },
  "dspace:catalog": { "@container": "@set" },
  "dspace:filter": { "@container": "@set" },
  "dct:description": { "@container": "@set" },
  "odrl:hasPolicy": { "@container": "@set" },
  "odrl:permission": { "@container": "@set" },
  "odrl:prohibition": { "@container": "@set" },
  "odrl:duty": { "@container": "@set" },
  "odrl:constraint": { "@container": "@set" }
}

Included are rules that specific elements should be an array even if there is only 1 entry (the "@container": "@set" directives). Which allows to the JSON-LD compaction algorithm with compact arrays.
This allows any valid JSON-LD document to be compacted into a predictable shape which can then be used inside code.

[sebbader-sap]

General support in the call on 03.08.2023.

Todos implied by this proposal:

• remove non-needed vocabularies from the context above
• rewrite context.json
• simplify the examples
• align with the JSON schema files (see Add missing attributes for the DCAT Catalog Schema and Shape #89)
• check the implications on profiling ODRL, DCAT etc.

We (the people working on these todos) will prepare one PR to illustrate the implications. In particular, this PR will also most likely solve #125 .