problems with JSONLD response

[VladimirAlexiev]

I tried converting the JSONLD Catalog Response to RDF and I found many problems.
They are described in detail at https://github.com/underpin-project/model/blob/main/dcat#dataspace-catalog-response (with saved files, conversion commands, images), below I reproduce only the two Problem sections:

• Canned Response Problems comes from your documentation https://edc-ce.docs.sovity.de/backend/what-is-the-management-api/openapi-specification/catalog
• Real Response Problems come from the simplest dataset in a self-installed EDC 0.8 Community Edition

A lot of the problems appear in both, ideally we'll merge them to a single checklist.
@tmberthold @jkbquabeck can you please check which have been fixed in 1.0?

Canned Response Problems

There are various defects in the EDC/Sovity canned response:

• Doesn't return the correct content-type: should be application/ld+json instead of application/json
• Doesn't import the "canonical" context specified in the Protocol, which is https://w3id.org/dspace/2024/1/context.json
  (see the first line of the diagram in Dataspace Protocol Catalog Response, and the example catalog.json)

Includes a deficient and defective context:

    "edc": "https://w3id.org/edc/v0.0.1/ns/",
    "dcat": "https://www.w3.org/ns/dcat/",
    "odrl": "http://www.w3.org/ns/odrl/2/",
    "dspace": "https://w3id.org/dspace/v0.8/"

• Uses wrong DCAT namespace.
  As you can see in the DCAT spec, the namespace for DCAT terms is http://www.w3.org/ns/dcat#
  (http not https, and trailing hash not slash)
• Uses obsolete dspace: namespace. The "canonical" context specifies https://w3id.org/dspace/2024/1/ (this is a minor problem since no dspace: terms are used)
• Doesn't specify a @base which means that all @id fields are incorrectly resolved to local file URLs (depending on the RDFization tool).
  • Eg <file:///D:/Onto/proj/underpin/model/dcat/5e839777-d93e-4785-8972-1005f51cf367>
• Uses a bad URI for odrl:Set, so we get this error from riot (see command below). The error means that the part before : is taken to be a URI scheme (completely wrong)

Not advised IRI: <OGU0ZTMzMGMtODQ2ZS00ZWMxLThmOGQtNWQxNWM0NmI2NmY4:YmNjYTYxYmUtZTgyZS00ZGE2LWJmZWMtOTcxNmE1NmNlZjM1:NDY2ZTZhMmEtNjQ1Yy00ZGQ0LWFlZDktMjdjNGJkZTU4MDNj> 
Code: 11/LOWERCASE_PREFERRED in SCHEME: lowercase is preferred in this component

• Doesn't define the @type of properties:
  • This leads to a disconnected RDF graph:
    • odrl:target "bcca61be-e82e-4da6-bfec-9716a56cef35" is a string,
      so it doesn't point to the Dataset URI <file:///D:/Onto/proj/underpin/model/dcat/bcca61be-e82e-4da6-bfec-9716a56cef35>
    • dcat:accessService "5e839777-d93e-4785-8972-1005f51cf367" is a string,
      so it doesn't point to the DataService URI <file:///D:/Onto/proj/underpin/model/dcat/5e839777-d93e-4785-8972-1005f51cf367>
    • (Note: according to the DCAT spec, dcat:accessURL (if present) should be equal to dcat:accessService/dcat:endpointURL)
  • odrl:type, odrl:leftOperand, dct:endpointUrl, dcat:accessService should be URLs instead of strings
  • odrl:rightOperand should have datatype xsd:dateTimeStamp instead of string

There are also instance data problems:

• dct:format should be a IANA registered MIME type.
  Instead, it is declared @id and is a fake/free-text string (eg "HttpData"), leading to a non-sensical URL: file:///D:/Onto/proj/underpin/model/dcat/HttpData
• dct:endpointUrl is a non-existent property, should be dcat:endpointURL
• dct:terms is a non-existent property, don't know what was meant here

Real Response Problems

The real response has even more problems than the canned response:

• Lacks dcat:Distribution (maybe the way we tried to add it was wrong)
• Doesn't define or use prefixes for foaf, dcat-ext, dct
• Uses both prefixed URLs with wrong prefix, and full URLs, eg:
  • dcat:Dataset, dcat:service use wrong prefix, http://www.w3.org/ns/dcat#keyword is right but unshortened
  • dct:terms uses wrong prefix, http://purl.org/dc/terms/license is right but unshortened
• Doesn't define @base so relative URLs are resolved to "random" full URLs
• The @id of odrl:Set uses bad chars, so it is unsuitable as URI. If you look at the Turtle above, it's discarded (so that node obtains only the random base URL)
• Uses a nested node {"odrl:action": {"odrl:type": ...}} but:
  • The ODRL Information Model 2.2 doesn't define odrl:type
  • The odrl.jsonld context doesn't define such term.
    It aliases "type": "@type" but that means rdf:type and not odrl:type
  • None of the "action" examples show such "type" subnode
• Uses a plain string "USE" as the value. But:
  • The IDSA Contract JSON schema uses prefixed URLs, and one of the allowed values is "odrl:use"
  • The odrl.jsonld context specifies that it's a URL (@vocab means that by default it's resolved in the vocabulary namespace):

"action": {
  "@type": "@vocab",
  "@id": "odrl:action"
}

• dct:endpointUrl is a non-existent property, should be dcat:endpointURL
• dct:terms is a non-existent property, don't know what is meant here
• The following are not declared as URL properties: odrl:target, dct:endpointUrl, dcat:landingPage, dct:license, dct:language
  • In particular, odrl:target doesn't link to the dcat:Dataset node
  • I checked, https://w3id.org/idsa/code/EN resolves and returns the complete IDSA ontology where that code is defined
    (IDSA uses a single namespace for all kinds of codes)
• The dcat-ext:httpDatasourceHintsProxy* props carry the string "false" and lack the datatype xsd:boolean

[tmberthold]

Hello and thank you for this discussion.

At first glance I personally am not a spec/namespace-expert and I think that many of the reported problems come from the core-edc used and should actually be addressed at core-edc level and in their specification-rounds.

Nevertheless, I will pass this on internally.

[VladimirAlexiev]

Which git projects are "core-edc and their specification-rounds"?

When you reuse an ontology/context, you are obligated to use the namespaces exactly as given.
Eg I personally prefer https but many ontologies use http.

Related:

• problem with odrl:target shape International-Data-Spaces-Association/ids-specification#276
• context should define more props as @id International-Data-Spaces-Association/ids-specification#277

[tmberthold]

This sovity EDC is based on the open-source core-edc implementation located here: https://github.com/eclipse-edc/Connector

The (new) repo for the Dataspace Protocol is here: https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol

However, I have also forwarded the discussion internally.

[VladimirAlexiev]

Ok, I'll await reply which of these problems are fixed in EDC/Sovity 1.0 (hope I'm citing the version correctly)

[SebastianOpriel]

Hi @VladimirAlexiev first of all I really appreciate your feedback! I worked my way through your thorough feedback but indeed only scratch at the surface with my first comments. To process all your doubts and comments we will take longer to sort out things we can change and which are coming from DataSpaceProtocol (DSP) Specification or Core EDC, which implements the DSP. First points:

Doesn't return the correct content-type: should be application/ld+json instead of application/json

You are right, I started a discussion here: International-Data-Spaces-Association/ids-specification#278

Doesn't import the "canonical" context specified in the Protocol

You are linking to the most recent version of the Data Space Protocol in v1.0. Your current connectors follow the more mature version 0.8 of DSP with Core EDC v0.2.1. We are in the progress of migration towards 0.7.x for our non-Catena-X customers and can provide you after the migration an updated version. Nevertheless I tested the response also with an Catena-X compliant Connector already based on 0.7.x, I can see the same mismatch between specification and current Core EDC implementation. I opened a discussion here eclipse-edc/Connector#4624

Uses wrong DCAT namespace.

This was identified by us in the past and fixed by the Core EDC team see eclipse-edc/Connector#3458 Our upcoming Connector will incorporate this fix.

dct:endpointUrl is a non-existent property, should be dcat:endpointURL

This was fixed in Core EDC v0.10.0 here. Our goal is to use a most recent version which is usable and compatible with different Data Spaces like Catena-X. Thus, I need to ask for patience about adopting Core EDC >0.10.0.

[VladimirAlexiev]

Hi @SebastianOpriel and @tmberthold ! Has Sovity tested some of these issues using the latest EDC version?
One excuse of the EDC team in eclipse-edc/Connector#3458 was that we're reporting against a version is that's a year old.
Thanks in advance!