w3c/poe

Permissions & Obligations Expression WG

Permissions & Obligations Expression WG

Documents produced by the Permissions & Obligations Expression WG of the W3C.

See also a paged view of the documents served in HTML.

If you are member of the working group, and you wish to contribute to the content of this repo, please contact Ivan Herman ([email protected]), giving him your github login.

poe's Issues

Clarify Party definition

Need to define Party more generically, not based on role

Links from Scenarios to Encodings

Add links from each Scenario to the corresponding Encoding example in the Vocab/Express WD.

Add RDF/OWL Encoding section

Add the RDF/OWL encoding section (parts/rdfowl.html).
Anything that is not covered in Vocab section and specific to RDF/OWL encodings.

Check Policy Types

Review each policy type and ensure covers the correct semantics and any constraints.

Add license example

Add the below to the RDF/OWL encoding section (it was par of the Set example)

Because all of the rules associated with this policy have the same target, and do not have any constraints or duties (requirements), one may abbreviate the expression of the policy and use the Dublin Core rights or license predicates to associate the asset with that policy:

@Prefix odrl: http://www.w3.org/ns/odrl/2/ .
@Prefix dct: http://purl.org/dc/terms/ .

http://example.com/asset:9898 dct:license http://example.com/policy:0099 .

http://example.com/policy:0099
a odrl:Set;
odrl:permission odrl:reproduce ;
odrl:prohibition odrl:modify .

Clarify Duty obligation

Need to clarify that Duties must be performed but when (at what point in time) is not specified (by default).

Updated Figure

Create an updated Figure (Section 4) that shows the vocabulary structure

Add more examples inline to Info Model

Review info model to support "annotation model" style examples
(see https://www.w3.org/2016/poe/track/actions/27)

Ontology status property

Do we need the "status" property for each and all of the ontology terms?
The status is reflected at the spec-level.
Suggest we remove them.

Clarify contradictory values of conflict attribute

Need to clarify conflicting values of the conflict attribute. That is, one policy says perm and the other prohibit.

Feedback from CG on Vocab/Onto/Model

There are some vocab/onto/model issues listed here we should address:
https://lists.w3.org/Archives/Public/public-odrl/2016May/0005.html

Policy Versioning

Propose a set of versioning attributes (model) and properties (vocab) for Policies that indicate the validity period of the policy.
See https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.04_Support_versioning_policies

Clarify Duty for Permissions only

Need to clarify that Prohibitions cannot have Duties

Add Constraint to Party and Asset

Add Constraint model to Party and Asset.

See: https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.01_Define_how_constraints_on_a_party_can_be_expressed_.28Migrated.29

Also addresses:
https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.07_Define_a_category_property_for_class_Party

https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.08_Add_a_category_property_to_Asset

Add Assertion Type

Add a new Assertion policy Type

See https://www.w3.org/2016/poe/wiki/Requirements#POE.R.V.16_Assertion_Policy_Type

JSON examples

All of the JSON examples (except the first) do not show up in the Scenarios section

Documentation properties

We currently use rdfs:comment to capture both the definition and comment from the original ODRL Vocabulary spec.
I propose we now use:
skos:definition for the definition
skos:scopeNote for the comments

Fixed use of deprecated Pay duty in Scenarios

Update to use Compensate

Add Privacy Considerations section

Add Privacy Considerations section

Support JSON-LD

We will support JSON-LD serialisation (not current JSON as in V2.1) as close as possible to ODRL Ontology.
Update spec. required.

Clarify inheritance and over-riden entities

We need to make clear exactly what gets inherited and what gets over-riden (if anything)

Permission cardinality

Section 2 says that "an ODRL Policy must contain at least one Permission" but the UML model shows 0..*

Add compensatingParty

Add new party role: compensatingParty
(to match compensatedParty)

See https://www.w3.org/2016/poe/wiki/Requirements#POE.R.V.10_Add_terms_to_the_Roles_of_a_Party_Vocabulary

The spec uses the term ODRL but never says what that is

There is an expansion of it in the informative references... but that's sort of obscure.

Add Appendix for Changes from the Community groups specs

Add and appendix to enable documenting the changes from the ODRL Community groups reports (vocab, xml, ontology, json)

Ordering of the contents of the Vocab section

Here is a proposed ordering of the Vocab section:
1 - Model Concepts
2 - Policy Types
3 - Actions for Permissions/Prohibitions
4 - Actions for Duties
5 - Constraints
6 - Constraint Operators
7 - Party Roles
8 - Party Scopes
9 - Asset Relations
10 - Deprecated Concepts

How to do this from the owl ontology?
For classes we can group them into SKOS collections.
For properties?
For individuals?

Reference links not working

Links to references in the Vocab tables does not work (and respec does not see them)
eg [iso8601]

Versioning of the Encodings

Since we have not completed the final use case and requirements analysis, we are yet to determine if the final ODRL will be a significant change to V2.1 - and maybe backwards incompatible.

For now, we can refer to all encodings as Version 2.2 until we make the final call.

Inverse Target Link

Support inverse target link only: targetURI policyURI

• defined by vocabulary (narrative in model)

See: https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.03_Introduce_policy_template

Describe more options for Target Asset URI

The URI used for the target Asset may not just point to a single resource.
Explain additional options, such as:

• media fragments
• POWDER
• RFC6570
• URI wildcards

rightOperand is a reference to a value

Add support to indicate that the rightOperand is a reference (URI) to a value, not the value itself.

See: https://www.w3.org/2016/poe/wiki/Requirements#POE.R.E.01_Referring_to_external_resources_for_defining_payment_fees

Clarify/Revise outlined semantics of Extended Relations

I've some concerns with the outlined semantics of Extended Relations as defined in Section 6.1 [1].

For example, for Permissions and Prohibitions it reads as follows:

Permission

OR The related party may perform any (at least) one of the Actions
AND The related party MUST perform all of the Actions
XOR The related party MAY perform only one of the Actions

1. I would argue that by granting someone the permission to perform a certain action does NOT imply that respective party MUST actually perform permitted action. The Assignee is permitted to do it, but doesn't have to.

Prohibition

OR The related party MAY NOT perform at least one of the Actions
AND The related party MAY NOT perform all of the Actions
XOR The related party MAY NOT perform only one of the Actions

1. There is no definition of "MAY NOT" in RFC 2119 (afaik).
2. Apart from (1), "MAY NOT" doesn't reflect the intended semantics of, e.g., AND-ed Prohibitions (imho). E.g., if someone is prohibited to neither print nor display a certain asset, that person MUST NOT perform actions print AND display on a certain asset. (cf. SHOULD NOT)

Besides that, I'm actually wondering whether there's any use case that would motivate/require AND-/OR-/XOR-ing Permissions/Prohibitions?

[1] https://w3c.github.io/poe/model/#extended-relations
[2] https://tools.ietf.org/html/rfc2119

Include Rule in the UML Model

Include Rule in the normative Information Model? Rule appears in the Ontology as an abstract class already

Clarify role of conflict resolution

Conflict is not only used for resolving merge issues but also between perms/prohibits in the same policy

ODRL Profiles

Move section to new Top-level Section (to show its importance).
Update the narrative

Add Acknowledgement section

See the 2.1 community spec

Concept Table visual look

Need to decide on the visual look of the table describing each concept.
Two options are attached.
Feedback and other options welcome

Subject of the Constraint

Add new property to Constrait model to indicate (the assumed) subject

See: https://www.w3.org/2016/poe/wiki/Requirements#POE.R.DM.02_Define_target_of_a_constraint

Update Vocab terms names and Inheritance in Model

At the TPAC meeting, I took the action [1] to look at some of the minor suggestions published in this ODRL review paper [2].

I recommend we adopt the following changes to the Vocabulary terms (as label changes, not the URI):

undefined: handle Undefined Actions
support: support Undefined Actions
ignore: ignore Undefined Actions
invalid: invalidate Policy

conflict: handle Policy Conflicts
perm: prefer Permissions
prohibit: prefer Prohibitions

I recommend the following changes to the ODRL Information Model:

1 - update the narrative with the new wording described above.
2 - update thge Policy Class (in the UML Diagram Figure 1) and make the inheritFrom attribute an Association (pointing to itself) and the inheritRelation attribute as an Association Class linked to this new Association.

[1] https://www.w3.org/2016/poe/track/actions/26
[2] http://subs.emis.de/LNI/Proceedings/Proceedings220/3081.pdf

Deprecation predicate

Should we use owl:deprecated predicate (instead of ont:deprecatedBy)?
And is rdf:nil the appropriate value for a concept deprecated (but not by another concept)
Should we also remove (ontological) links to deprecated terms?

vCard Ref

Update vCard ref to W3C vCard Ontology spec (as this has URIs to use) and consistent with Vocab spec

Add Appendices for XML/JSON Schemas

Add two Appendices to read in the XML and JSON schemas and show them for human-readability.
They can also be linked directly from the document (as it is now).

Vocabulary naming

Ensure that the Label used for the terms do not differ just in case (eg Action, action) as this will not meet I18N requirements.

MAY vs SHOULD

Check all the MAY options and see if SHOULD is better.
As per https://tools.ietf.org/html/rfc2119

Add "unit-of-count

Add XML encoding section

Add the XML encoding section

Add unit-of-count

Add a unit-of-count to the Constraint

See: https://www.w3.org/2016/poe/wiki/Requirements#POE.R.V.03_Add_concept_of_.27unit-of-count.27_to_Duty_Constraint_Vocabulary

Add JSON encoding section

Add the JSON encoding section (parts/json.html)

Ontology constraints/restrictions

We should look at defining some of the ontology entities (eg the Policy Types) with more constraints that reflect their semantics. eg Agreement class must have assigner and assignee, etc.
We should look into using SHACL as well, were appropriate.

TimeInterval range

Update the range of the TimeInterval property to xsd:duration