From 629bce83d9952a01e6d85e900b1a3b51a12455a4 Mon Sep 17 00:00:00 2001 From: tonys Date: Tue, 16 Jun 2026 16:50:19 +0100 Subject: [PATCH 1/2] Added in the abstract property. for life cycle status --- dprod-contracts/docs/specification.md | 39 ++++++++++++++++++++++----- dprod-contracts/dprod-contracts.ttl | 38 ++++++++++++++++++++++++++ 2 files changed, 70 insertions(+), 7 deletions(-) diff --git a/dprod-contracts/docs/specification.md b/dprod-contracts/docs/specification.md index 1ae2df7..244f4df 100644 --- a/dprod-contracts/docs/specification.md +++ b/dprod-contracts/docs/specification.md @@ -161,15 +161,40 @@ ex:subscription a dprod:DataContract ; ## 4. Property Definitions -### 4.1 dprod:offerLifeCycleStatus, dprod:contractLifeCycleStatus, dprod:dutyState +### 4.1 Lifecycle status properties -| Property | Domain | Range | Cardinality | Definition | -|----------|--------|-------|-------------|------------| -| `dprod:offerLifeCycleStatus` | `dprod:DataOffer` | `skos:Concept` | 0..1 | Administrative lifecycle status of a data offer (not evaluated at request time) | -| `dprod:contractLifeCycleStatus` | `dprod:DataContract` | `skos:Concept` | 0..1 | Administrative lifecycle status of a data contract (not evaluated at request time) | -| `dprod:dutyState` | `odrl:Duty` | `skos:Concept` | 0..1 | Evaluated state of a duty (set by the standard evaluation algorithm; see §5 of formal-semantics.md) | +DPROD uses a single abstract super-property — **`dprod:lifeCycleStatus`** — as the default pattern for "where is this resource in its lifecycle" properties. Concrete lifecycle statuses pin the property to a specific resource class via `rdfs:domain` and keep `skos:Concept` as the range, so each domain can plug in an appropriate `skos:ConceptScheme` without re-closing the value set. -All three properties are `owl:ObjectProperty`. The four DPROD-defined canonical concepts (`dprod:Pending`, `dprod:Active`, `dprod:Fulfilled`, `dprod:Violated`) form the default vocabulary for each; profiles MAY introduce further `skos:Concept` values. +| Property | Super-property | Domain | Range | Cardinality | Definition | +|----------|---------------|--------|-------|-------------|------------| +| `dprod:lifeCycleStatus` | — (abstract) | — | `skos:Concept` | 0..1 | Abstract: position of any DPROD resource in its lifecycle | +| `dprod:offerLifeCycleStatus` | `dprod:lifeCycleStatus` | `dprod:DataOffer` | `skos:Concept` | 0..1 | Publication lifecycle position of a data offer; assigned by the publisher | +| `dprod:contractLifeCycleStatus` | `dprod:lifeCycleStatus` | `dprod:DataContract` | `skos:Concept` | 0..1 | Administrative lifecycle position of a data contract; assigned by the contract management process | +| `dprod:lifecycleStatus` | `dprod:lifeCycleStatus` | `dprod:DataProduct` | `dprod:DataProductLifecycleStatus` (⊆ `skos:Concept`) | 0..1 | Development lifecycle of a data product (main DPROD; pre-existing) | + +The data-product property `dprod:lifecycleStatus` predates the SKOS-based pattern; it is folded into the family by two compatibility axioms in `dprod-contracts.ttl`: `dprod:lifecycleStatus rdfs:subPropertyOf dprod:lifeCycleStatus` and `dprod:DataProductLifecycleStatus rdfs:subClassOf skos:Concept`. Existing data-product values remain valid. + +The `dprod:DataContractLifeCycleStatus` concept scheme (§3.1) is the default vocabulary for `offerLifeCycleStatus` and `contractLifeCycleStatus`; the `dprod:DataProductLifecycleStatus` enumeration is the default for `lifecycleStatus`. Profiles MAY use either as-is, extend them via `skos:inScheme`, or supply their own scheme. + +#### Why `dprod:dutyState` is not part of this hierarchy + +`dprod:dutyState` is **not** a sub-property of `dprod:lifeCycleStatus`. Lifecycle statuses are *authored* — the value is assigned by a known actor (publisher, contract manager, data product owner) and stays put until that actor changes it. `dprod:dutyState`, by contrast, is *computed* — the value is the latest output of an evaluator running against observable facts. Mixing the two under a common super-property would obscure the most useful distinction: who owns the value and when it changes. + +### 4.1.1 Pattern for new lifecycle status properties + +When a new DPROD resource needs a lifecycle status, follow this pattern: + +```turtle +dprod:someResourceLifeCycleStatus + a owl:ObjectProperty ; + rdfs:subPropertyOf dprod:lifeCycleStatus ; + rdfs:domain dprod:SomeResource ; + rdfs:range skos:Concept ; + rdfs:label "some resource life cycle status" ; +. +``` + +A matching `skos:ConceptScheme` SHOULD be supplied as the default vocabulary, but the property MUST NOT re-close its range as an `owl:Class` enumeration — the open `skos:Concept` range is what lets profiles plug in their own concepts without breaking conformance. ### 4.2 dprod:deadline diff --git a/dprod-contracts/dprod-contracts.ttl b/dprod-contracts/dprod-contracts.ttl index 28bb7ad..34203da 100644 --- a/dprod-contracts/dprod-contracts.ttl +++ b/dprod-contracts/dprod-contracts.ttl @@ -159,8 +159,27 @@ dprod:Violated ############################# DPROD Contracts Properties ################ +# Abstract super-property establishing the default DPROD pattern for lifecycle +# status properties. Concrete lifecycle statuses (offer, contract, data product) +# are sub-properties of this one with the same skos:Concept range but a +# domain-specific class. New DPROD properties expressing "where is this thing +# in its lifecycle" SHOULD follow this pattern. +dprod:lifeCycleStatus + a owl:ObjectProperty ; + dct:description "Abstract: the current position of a DPROD resource in its lifecycle."@en ; + rdfs:comment + """Default DPROD pattern for lifecycle status properties. A concrete + sub-property pins the property to a specific resource class via + rdfs:domain and SHOULD keep skos:Concept as its range — letting each + domain plug in an appropriate skos:ConceptScheme."""@en ; + rdfs:isDefinedBy dprod: ; + rdfs:range skos:Concept ; + rdfs:label "life cycle status" ; +. + dprod:offerLifeCycleStatus a owl:ObjectProperty ; + rdfs:subPropertyOf dprod:lifeCycleStatus ; dct:description "Where this offer sits in its publication lifecycle — typically drafted, published, withdrawn, or superseded; assigned by the publisher."@en ; rdfs:comment """Value is any skos:Concept; dprod:DataContractLifeCycleStatus is one @@ -173,6 +192,7 @@ dprod:offerLifeCycleStatus dprod:contractLifeCycleStatus a owl:ObjectProperty ; + rdfs:subPropertyOf dprod:lifeCycleStatus ; dct:description "Where this contract sits in its administrative lifecycle — typically pre-effective, in force, completed, or breached; assigned by the contract management process."@en ; rdfs:comment """Value is any skos:Concept; dprod:DataContractLifeCycleStatus is one @@ -360,3 +380,21 @@ dprod:currentDateTime rdfs:label "current date time" ; rdfs:seeAlso odrl:dateTime ; . + + +############################# Compatibility axioms against main DPROD ################ +# These axioms fold pre-existing main-DPROD terms into the lifecycle-status pattern +# established above. They live here (rather than in main dprod-ontology.ttl) because +# this file is the contract for "additional axioms against the DPROD ontology", and +# the pattern itself was introduced with dprod-contracts. + +# Make the existing dprod:lifecycleStatus (data product) a sub-property of the new +# abstract dprod:lifeCycleStatus. The existing property's range (dprod:DataProductLifecycleStatus) +# is narrower than skos:Concept, so the next axiom is needed to keep values valid +# under both the existing and the inherited range constraints. +dprod:lifecycleStatus rdfs:subPropertyOf dprod:lifeCycleStatus . + +# Fold the existing enumeration class into SKOS so that any +# dprod:DataProductLifecycleStatus individual is also a skos:Concept (and therefore +# a valid value of dprod:lifeCycleStatus and any sub-property thereof). +dprod:DataProductLifecycleStatus rdfs:subClassOf skos:Concept . From 1ff101103261dc692a649855f5867f8d590221a6 Mon Sep 17 00:00:00 2001 From: tonys Date: Tue, 16 Jun 2026 17:12:46 +0100 Subject: [PATCH 2/2] For now 5.8 and 5.9 we're rejecting but let's see what Stephen says. --- dprod-contracts/docs/changes-plan.md | 1 + dprod-contracts/docs/contracts-guide.md | 12 +----------- 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/dprod-contracts/docs/changes-plan.md b/dprod-contracts/docs/changes-plan.md index 3be5e9e..f60a272 100644 --- a/dprod-contracts/docs/changes-plan.md +++ b/dprod-contracts/docs/changes-plan.md @@ -343,6 +343,7 @@ Source: 19da58f8 (full proposal in recurrence-redesign.md). - Decision: **(a)** Change `dprod-shapes:DataContractShape` `dprod:acceptsOffer` to `sh:minCount 1` only (drop `sh:maxCount`), accepting the basket model. Or **(b)** Keep `1`, document the workaround (one mega-offer + selective obligation refs). Or **(c)** Add a sibling property `dprod:acceptsOffers` (plural, basket) and keep `acceptsOffer` as the single-offer shorthand. - Coupling: depends on 5.8. Whatever is decided here, the formal-semantics resolve algorithm (norm matching across the contract's offers) needs an explicit rule. +## TSNOTE: for now we're rejecting 5.8 and 5.9 as it seems to increase complexity rather than reduce it. Interest here from Stephen on the justifications. --- ## Bucket 6 — Deferred / needs more info diff --git a/dprod-contracts/docs/contracts-guide.md b/dprod-contracts/docs/contracts-guide.md index 3f3ebbb..3a5eb23 100644 --- a/dprod-contracts/docs/contracts-guide.md +++ b/dprod-contracts/docs/contracts-guide.md @@ -396,18 +396,8 @@ ex:contract a dprod:DataOffer ; odrl:permission [ a odrl:Permission ; odrl:action odrl:read ; - odrl:target ex:marketPrices ] ; - odrl:permission [ - a odrl:Permission ; - odrl:action odrl:read ; - odrl:target ex:referenceData - ] ; - odrl:permission [ - a odrl:Permission ; - odrl:action odrl:read ; - odrl:target ex:riskMetrics - ] . +. ``` ---