`timestamp` format string or complex object?

International-Data-Spaces-Association / ids-specification

The Dataspace Protocol is a set of specifications designed to facilitate interoperable data sharing between entities governed by usage control and based on Web technologies. These specifications define the schemas and protocols required for entities to publish data, negotiate Agreements, and access data in a data space

https://docs.internationaldataspaces.org/dataspace-protocol/

Apache License 2.0

26 stars 14 forks source link

`timestamp` format string or complex object? #132

Closed matgnt closed 10 months ago

matgnt commented 1 year ago

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 commented 1 year ago

Currently the following options are possible:

"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? :-))
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
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)
OWL Time (as demanded by DCAT): See: https://www.w3.org/TR/owl-time/#time:Instant Problem: complete overkill
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 commented 1 year ago

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 commented 1 year ago

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

looks very good!

sebbader-sap commented 1 year ago

"@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 commented 1 year ago

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 commented 12 months ago

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 commented 11 months ago

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 commented 11 months ago

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 #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 .