See https://github.com/EKGF/dprod/issues/118
Should use https://www.omg.org/spec/DPROD/ like other standard ontologies.
This will have a large impact and should be done before making the spec final.

See https://github.com/EKGF/dprod/issues/77
In my experience cataloging data products, it is often desirable to express a (input) dependency between data products, as supposed to express a (input) dependency of a data product on (other) datasets. So my request would be to have an objectproperty between two data products that declares that one data product uses the data from another data product (without having to specify which specific dataset).

See https://github.com/EKGF/dprod/issues/86
Dataspaces is a huge thing in Europe and is used in numerous industries for sharing of commercial/protected (not open) data.
Dataspaces use odrl:Offer and then a very simple "contract negotiation" protocol. Please add an example along these lines:
https://docs.internationaldataspaces.org/ids-knowledgebase/v/dataspace-protocol/contract-negotiation/contract.negotiation.protocol

See https://github.com/EKGF/dprod/issues/76
I would have expected either:
inputDataset and outputDataset to be modelled using prov semantics (either just as prov:wasDerivedFrom/prov/used or as a subProperty of it).
or, if the semantics is distinct from prov, that the nuance is clarified at the very least in the documentation, but ideally also through machine readable relationships (something like owl:differentFrom).

See https://github.com/EKGF/dprod/issues/98
Shapes reference dcat:Protocol and dcat:SecuritySchemaType which are in dprod:

See https://github.com/EKGF/dprod/issues/101
In the Core Data Product Extensions example,
"@type": "ex:DataProductagreement"
should be capital A
"@type": "ex:DataProductAgreement"

See https://github.com/EKGF/dprod/issues/97
The spec document includes the URI for properties, to make clear which ontology they're from, but not for classes e.g. DataService (which actually comes from DCAT)

See https://github.com/EKGF/dprod/issues/82
Should use "spatial" not "region"

See https://github.com/EKGF/dprod/issues/81
odrl:targets should be odrl:target.
It's fixed in the source but not the specification document.

https://github.com/EKGF/dprod/issues/79
For example:

Identifier: rdfs:label
Label: data product label shape
Domain: dprod:DataProduct
Range: xsd:string

probably the "shape" should not be included in the rdfs:label for the Shape too, so it could also be used as the basis of forms etc.

See https://github.com/EKGF/dprod/issues/28
Though DPROD does not include actual resources for these values, the example list should be complete in the dct:description.

Some domain and range hyperlinks redirect browsers to the DCAT 2 specification.

For example: https://ekgf.github.io/dprod/#inputdataset . If you click on the Range link it takes you back to DCAT 2 .

See https://github.com/EKGF/dprod/blame/a78e2f110d9ec729fbe6f74317db3b379cfade56/examples/data-rights/example.json#L5.

1. Example doesn't look like valid JSON.
2. Neither does "rightOperand": [region:EMEA, region:APAC] in the same file.

Note: Github issues #110

https://github.com/EKGF/dprod/issues/94
The diagram https://ekgf.github.io/dprod/#data-product-dprod-model should:

• show the prefix of each term
• spell the actual class name: Data Product -> dprod:DataProduct
• fix the misspelling conformTo -> dct:conformsTo

E.g. examples/data-quality/example.json is a JSON-LD file.
Some JSON/LD files do not have a proper extension, required for tools.

Rename all of the JSON/LD files to *.jsonld

https://github.com/EKGF/dprod/issues/73

Diagram & this link https://github.com/EKGF/data-product-spec/blob/main/dprod.ttl

Both include dprod:productionProcessDescription.

Neither of the more recent ttl files at https://github.com/EKGF/dprod/tree/main/ontology/dprod do have this property.

See https://github.com/EKGF/dprod/issues/29

When more than one users are updating a KA concurrently, only the last update prevails. Some sort of locking is necessary.

An 'optimistic locking' scheme is proposed:

• Upon reading an artifact, it MUST deliver its versionTag.
• When updating an artifact, the caller MUST specify the versionTag upon which the change was made. If another change has meanwhile created a new version, the update referencing a previous version must be refused.

The OpenAPI definitions and the schemata are affected.

Just as in software development there will be sooner or later the need for branching and merging trails of work on knowledge artifacts. There are more and less complicated approaches to the same repository or (more importantly even) including multiple repositories.

Let us discuss the need and possible solutions. No need to prepare a design, in case the use-case is not rated high enough.