feat(contracts): dprod:lifeCycleStatus super-property; reject \xc2\xa75.8/\xc2\xa75.9 pending Stephen

[tonyseale]

Summary

Two small follow-ups to #199 (now merged on develop):

1. Abstract lifecycle-status super-property

Introduces dprod:lifeCycleStatus as the default DPROD pattern for "where is this resource in its lifecycle" properties. The three concrete lifecycle properties become sub-properties:

• dprod:offerLifeCycleStatus (on dprod:DataOffer)
• dprod:contractLifeCycleStatus (on dprod:DataContract)
• dprod:lifecycleStatus (on dprod:DataProduct, pre-existing in main DPROD)

The data-product property is folded into the family non-destructively via two additional axioms in dprod-contracts.ttl:

dprod:lifecycleStatus rdfs:subPropertyOf dprod:lifeCycleStatus .
dprod:DataProductLifecycleStatus rdfs:subClassOf skos:Concept .

The second axiom keeps existing dprod:DataProductLifecycleStatus instances valid as skos:Concept values under the inherited range. dprod:dutyState is deliberately not a sub-property — it is an evaluator-computed state, not an authored lifecycle status.

Spec §4.1 rewritten as a property hierarchy table; §4.1.1 added with the recommended Turtle pattern for new lifecycle properties.

2. §5.8 and §5.9 rejected for now (pending Stephen)

A TSNOTE appended to changes-plan.md records that the basket-model proposals (§5.8 single-target DataOffer; §5.9 1..* dprod:acceptsOffer) are being rejected for now because they "seem to increase complexity rather than reduce it." Stephen's original proposal text in §5.8 and §5.9 is left intact for him to respond to. No shape changes, no example refactor, no formal-semantics changes — the basket model is not implemented in this PR.

The small edit to contracts-guide.md (dropping the multi-target example) is a docs tidy that came along while reading the section.

Files changed (4)

File	Purpose
dprod-contracts/dprod-contracts.ttl	New abstract super-property + two compatibility axioms
dprod-contracts/docs/specification.md	§4.1 hierarchy table + §4.1.1 pattern guidance
dprod-contracts/docs/changes-plan.md	TSNOTE rejecting §5.8/§5.9 pending Stephen
dprod-contracts/docs/contracts-guide.md	Small tidy (drop multi-target example)

dprod-contracts-shapes.ttl is not touched — DataOfferShape.odrl:target is still unconstrained, DataContractShape.dprod:acceptsOffer is still sh:maxCount 1.

Test plan

• Ontology + shapes parse cleanly.
• All four example policies (baseline, data-contract, data-use-policy, odcs) still validate with zero pyshacl recursion warnings.
• Verified the three sub-property links and DataProductLifecycleStatus rdfs:subClassOf skos:Concept resolve as expected.
• Verified dprod:dutyState is NOT in the new hierarchy.
• Verified DataOfferShape has no new odrl:target cardinality constraint (i.e. §5.8 is not silently landed).
• Verified DataContractShape.dprod:acceptsOffer still has sh:maxCount 1 (i.e. §5.9 is not silently landed).
• Stephen's response on the §5.8/§5.9 question (post-merge follow-up).

🤖 Generated with Claude Code

[vercel]

@tonyseale is attempting to deploy a commit to the EKGF Team on Vercel.

A member of the Team first needs to authorize it.