RE: Core Model Update

Hi Renato,

A typical use case for an ODRL Policy in the news industry might be:


1.       A news provider and a client have an existing agreement governing how the provider's content can be used by the client. This might be a document that was drafted in, say, 1968 and has been amended in various ways over the years. It is not actually represented in ODRL.

2.       A particular news item has a particular set of restrictions that mean that this one item cannot be used in a particular way, which would normally be permitted by the provider/client agreement. The limitations are expressed in ODRL and are attached in some way to the piece of content.

To make it slightly more concrete: the Example Photo Agency (EPA) has an agreement with the Example Newspaper (EN) which allows it to print and display online photographs. One particular photograph sent by the EPA to the EN has a restriction of "not for use in the UK".

If my understanding of what you say below is correct, then this can be expressed in an ODRL policy which says:

"This item can be used, as long as the location is NOT the UK"

This means that the Policy has a permission ("use") with a constraint ("not in the UK"). It would inherit the permissions of the existing agreement ("print" and "display online"). So, the EN would only be allowed to print or display online the photo, if the location wasn't the UK. I believe that is what these clarifications below would allow. But I just want to make sure.

Regards,

Stuart


From: Renato Iannella [mailto:ri@semanticidentity.com]
Sent: Tuesday, September 02, 2014 6:57 AM
To: ODRL Community Group
Subject: Core Model Update

Dear all, here is a proposal to clarify two issues in the Core Model.

1 - Permission/Prohibition context

Since there is some confusion as to how these two work together, it is proposed to add the following text (to section 2.0):

=====
The basic context of an ODRL Policy is that only an explicitly permitted use can be executed, any not permitted use is prohibited by default.

Based on that context, an ODRL Policy must contain at least one Permission and may contain Prohibitions.
An ODRL Policy only permits the action explicitly specified in a Permission and all other actions are implicitly prohibited.

An action defined in a Prohibition should only refine (or directly relate to) the semantics of an action defined in one of the Permissions in the
ODRL Policy.

For example, an ODRL Policy that has the action "present" Permission and may also have the action "print" Prohibition (as these actions are related
hierarchically in the ODRL Common Vocabulary).

Note that ODRL Profiles may refine the basic context of an ODRL Policy. Hence the use of an ODRL Profile must be understood by the consuming system.
=====

2 - Types of Inheritance

We currently state:
"The inheritRelation attribute in the (child) Policy will uniquely identify (via a UID) the type of inheritance from the (parent) Policy. For example, this may indicate the business scenario"

This is not clear as to how the "type" impacts with the actual inherited policy. The use case we want to support is that the current policy is "governed" by an some external policy, that you need to "inherit" the rules from, but it is not necessarily expressed as an actual ODRL Policy (what the inheritFrom attribute is expecting).

Hence we want to use the inheritFrom attribute and inheritRelation attribute independently (in some cases that typically would be documented in an ODRL Profile).

The proposal is to update the text of section 2.1.1. to clarify the above.


Comments/Feedback welcome.
Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com
Mobile: +61 4 1313 2206



The information contained in this communication is intended for the use
of the designated recipients named above. If the reader of this 
communication is not the intended recipient, you are hereby notified
that you have received this communication in error, and that any review,
dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please 
notify The Associated Press immediately by telephone at +1-212-621-1898 
and delete this email. Thank you.
[IP_US_DISC]

msk dccc60c6d2c3a6438f0cf467d9a4938