JSON-LD payloads in management/v2/asset API

[arnoweiss]

For a while now, the Asset-object in the EDC Management API has accepted json-ld as input. My assumption was that it is thus encouraged to write the actual asset registrations in json-ld. I'm slightly confused wrt how the EDC handles the data:

1. In some @context sections of json-ld payloads for relevant data assets, I have seen a namespace-prefix edc linking to https://w3id.org/edc/v0.0.1/ns/. Is there actually an ontology with a finite set of classes and terms behind this namespace-URI? If yes, how to find it? I think it would be valuable to have for such EDC-specific terms such as Asset, DataAddress etc specified somewhere.
2. As I understand, the EDC does not parse the incoming JSON-LD as RDF but as plain JSON. Is this correct and if yes, does that mean that reusing namespaces such as RDF, RDFS, OWL doesn't actually matter that much?
3. The DataAddress defines a field called "type". In JSON-LD, the blank-node behind the property "dataAddress" would have its rdf:type signified with "@type". Thus, a DataAddress could look like this:

  "edc:dataAddress": {
    "@type": "edc:DataAddress",
    "type": "HttpData",
    ...
}

That's not pretty since the two things can be mixed-up quite easily. Would it make sense to rename it?

4. What assumptions does the EDC make wrt the structure of the payload - for instance for a Asset? What properties are explicitly expected under what circumstances? Apart from the very loose json-schema in the openAPI spec, I wasn't able to find anything on this.

[arnoweiss]

Ad 3: The example here looks different yet with no @type property on the level of asset and dataAddress but just on the top-level with "AssetEntryDto".

[arnoweiss]

Ad 3: Here in CX - 0018,) it says that an Asset shall be styled as dcat:DataSet. Again, no examples, no json-schemas, nothing.

[jimmarino]

Ad 3: Here in CX - 0018,) it says that an Asset shall be styled as dcat:DataSet. Again, no examples, no json-schemas, nothing.

PRs are welcome :-) An effort is underway to provide examples and any help there would be appreciated. It's also a good way to start contributing to the project if you are interested.

Regarding your previous questions:

1. We will eventually provide a Json-LD context definition at that address for external systems that want it (the context is already cached in EDC), but it will not be an ontology.
2. I'm unsure what "EDC does not parse the incoming JSON-LD as RDF" means since Json-Ld is an RDF representation. EDC is namespace-aware - that's the primary reason we converted to Json-Ld. However, our concern in EDC (and the DSP specifications, by extension) is not in performing some form of semantic processing. That can certainly be done by externally processing data flowing through EDC (e.g., policy and asset properties), e.g., once it is received or persisted.
3. The type issue is being discussed in the Dataspace Protocol Specifications working group.
4. This is a broad question. Please take a look at the Decision Records and architecture documents where type extensibility is explained. The Asset type should be completely open to allow participants and dataspaces to define which properties are relevant to their use cases.

[sfiav]

Can somebody answer to question 1?

[jimmarino]

That was already answered, please see my response.