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/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/95 for discussion

As well as being useful, performing an automated conversion will serve to validate the JSON.
Original issue https://github.com/EKGF/dprod/issues/92

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/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

You declare 3 enumerations but no values for them:
`dprod:DataProductLifecycleStatus, dprod:InformationSensitivityClassification, dprod:SecuritySchemaType
That's not useful. Please collect at least an initial set of values. You cite 2 links, and there's also Wikidata, so you should be able to do it.
You can add a scopeNote that the enumeration is open, i.e. users are expected to add values.
For the last one you say dprod:securitySchemaType "# rdfs:range rdf:resource ; # better let user decide whether they want SecuritySchemaType class or own class or skos": that means the class SecuritySchemaType is doubly useless (the spec doesn't standardize members, and doesn't mandate its use)
Please consider using SKOS: it reduces the number of classes. To specify which skos:ConceptScheme is used by which prop, you can use the pattern adopted by ERA: they have an annotation property era:inSkosConceptScheme (Eg see LODE: improve name of inSkosConceptScheme Interoperable-data/ERA-Ontology-3.1.0#54)
(if you keep the current approach)
dprod:DataProductLifecycleStatusis declaredrdfs:subClassOfofdprod:Enumeration. But that should better be rdf:type, else Enumeration` will contain all kinds of values from various enumerations, which imho is not useful
Do that for the other enumerations as well

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

Following one of the conversations around security (dprod:securitySchemaType from November. There is the OIDC Connect Discovery that should be found in a /.well-known/openid-configuration location, so a DataService could specify:

...,
"securitySchemaType": "https://example.com/.well-known/openid-configuration"
...,
The content should look something like this:

There is no automatic way to create an account (and there are accounts for humans and "service accounts" for machines).

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

Can additional identifiers be added to support a richer expression of product details? Assuming data products become ubiquitous and the structure and purpose of data products evolves then the labelling/identification may also evolve. The overall/end-to-end product handling environment itself should become more standardised (e.g. considering/speculating on an architecture, but potential future need may arise to for large scale catalogs & product discovery methods, product stores, data product supply chains, data economy etc.)

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

Additional information would include, for example, data quality details for the data. General product details, product data sheets etc. These may not be of interest to everyone, and not necessarily needed to consume the data distribute through the service.

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

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/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/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