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

Review whether the DPROD spec should support roles beyond the current “owner,” such as help or contact roles. The design should account for potential future requirements to ensure flexibility in representing different responsibility types across resources.

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

Regenerate the DPROD specification site to reflect recent ontology and shape changes. Verify that all anchors, labels, and pages align with the updated models to ensure consistency and accuracy in the published documentation.

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

The current DPROD model defines both a dprod:Protocol class and a dprod:protocol property for describing service communication mechanisms, but it is unclear whether the class should be retained. This issue seeks a decision on whether to (A) keep and fully define dprod:Protocol with its own metadata properties and SHACL shape, or (B) remove it and instead reference external URIs or SKOS concepts directly from dprod:protocol.

Clarifying this will ensure consistency, clarity, and maintainability in how protocols are modeled across DPROD. The current approach introduces ambiguity around whether protocols should exist as structured internal entities or as references to external authoritative vocabularies. Resolving this will determine how richly metadata can be expressed, how interoperable the model is with external registries (e.g., IANA, W3C), and how closely DPROD aligns with linked data best practices.

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

The proposed issue seeks to clarify how information sensitivity should be modeled across different DPROD resource types. The current implementation limits dprod:informationSensitivityClassification to dcat:Dataset, but in practice, sensitivity distinctions may exist at finer levels, such as individual distributions or services. Aligning the ontology and SHACL shapes with real-world usage will improve consistency, expressiveness, and interoperability in sensitivity modeling.

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

Check if dcat:type is not included in the shape for DataProduct in the same way it is for DataSet.

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

While dcat:Resource supports the odrl:hasPolicy relationship, and dprod:* classes already inherit this capability, current DPROD shapes (particularly for dcat:DataService) do not explicitly include it. This leads to inconsistency between ontology-level support and shape-level best practices.

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