Ontology and shapes files have outdated dct:modified and owl:versionInfo. Better in any case to use owl:versionIRI.

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

Update the date information for ontology and shapes files

Update the date info

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.

Spec-site based on main branch, not ballot-4 branch nor develop branch

The spec website (as published on https://ekgf.github.io/dprod/) is generated automatically from the main branch (a very old but stable version). Not from the ballot-4 branch nor from the develop branch (into which ballot-4 will be merged).

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"

Fix typo in example

See detailed change https://github.com/EKGF/dprod/pull/168

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

Data Rights - Example 1

The fix ("region" → "spatial") was already applied in the source file examples/data-rights/README.md by @joshcornejo. The generated specification reflects the correct value. No further changes needed.

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.

Address the inconsistency by removing Protocol as a class, just a property

Remove the class and its NodeShape; and range from the Property

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

Add dprod-shapes prefix declaration

Add dprod-shapes prefix declaration

See
https://github.com/EKGF/dprod/issues/95 for discussion

Defer to allow further discussion

Deferred to allow further discussion on the proposed approach to replace explicit inverses.

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.

Fixed in DPROD-20

Fixed in DPROD-20

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)

Include URIs in documentation for each class in the specification

Add in the class URI

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

Correct references

Formal diff of changes here https://github.com/EKGF/dprod/pull/169

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.

Added "Retire" to the DataProductLifecycleStatus

Add a missing item ("Retire") to a controlled list of values for lifecycle

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

Defer to allow broader discussion

This requires broader 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

Defer to allow broader discussion

Deferred to allow for further discussion on examples of conversion, as proposed

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

Defer to allow broader discussion

This requires broader discussion

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.

Prevent SHACL shape labels leaking into spec

Remove the use of "Shape" in rdfs:label (in the documentation of the ontology)

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.

Defer for further discussion

Deferred for further discussion with concerned individuals on scope of information sensitivity

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.

Defer for further discussion

Deferred for further discussion with key individuals that can define additional roles.

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

Defer issue for broader discussion

This requires broader discussion.

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.

Defer for further discussion

Deferred for further discussion with key individuals on shape of DataProduct

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

Deferred to allow broader discussion

This requires broader discussion

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.

Consistently change URI in code and document

Global replace of URI and location from
https://ekgf.github.io/dprod
to
https:/www.omg.org/spec/DPROD

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

Defer to allow broader discussion

Needs discussion with interested parties and those involved.

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.

Defer for further discussion

Deferred for further discussion with key individuals on the topic of associated policy for specific fields

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).

Defer issue for broader discussion

This requires broader discussion so is deferred.

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).

Defer to allow broader discussion

Needs more discussion.

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

Correct json schema in data rights examples

In this page, https://github.com/EKGF/dprod/blame/a78e2f110d9ec729fbe6f74317db3b379cfade56/examples/data-rights/example.json#L5

fix the json schema line 5,
"assigner": 'https://schema.org/person/AdamSmith", and
in line 16,
"rightOperand": [region:EMEA, region:APAC],

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 .

Correct domain and range hyperlinks in DCAT specification

The reported problem is owing to DCAT having the same namespace across versions.

The issue is being resolved per this page: https://github.com/w3c/dxwg/pull/1618

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

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

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

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

Update diagram

Update diagram with fixes requested

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.

Updated the diagram

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