Discovery of an ODRL resource

[csarven]

Use case: agent wants to know how to display or further process policies directly associated with a resource.

If the ODRL policies are managed separately from the resources it describes, there needs to be a way to discover the policies.

What is the discovery path for agents starting with a resource that wants to find out about the ODRL resource (including information on policies, rules, actions, permissions, prohibitions, duties, assets, parties, constraints).

Is there an intended ODRL "protocol"? Is it in this CG scope?

By protocol, I mean something very lightweight eg:

HEAD /foo

200
Link: <https://example.org/foo.odrl>; rel="odrl"

(or along the lines of Link: <https://example.org/foo.odrl>; rel="http://www.w3.org/ns/odrl/2/rights">)

Certainly ODRL information can be discovered on the data layer (using whatever most appropriate property):

<https://example.org/foo>
   <http://purl.org/dc/terms/rights> <https://example.org/foo.odrl> .

but I'm primarily interested in the discovery of a resource that may hold all ODRL information about the associated resource. When the general use case is taken in context of authorization, discovery through the HTTP header would allow the consumer to get further details about the target.

[nitmws]

A few thoughts on that:

1. How to express a link to an ODRL policy related to a resource depends on how metadata about this resource can be expressed in general.
   I'm active at IPTC, the standards body of the news industry: a text news resource is in most cases an XML or JSON document providing the content and metadata about it, current IPTC standards allow to add a link to an ODRL policy. Image files have the metadata embedded, the embedded IPTC metadata (most widely used) support a link to an ODRL policy. Videos can have metadata embedded, the same as for images applies, and the IPTC metadata for videos held outside the video file also allow a link to an ODRL policy.
   By my experience for most of the text/image/video/audio assets a metadata standard exists and it has to be checked if it supports either inline ODRL data or a link to an ODRL policy.

2. ... an asset published on a web page can also have metadata in its HTML, e.g. a JSON-LD object with schema.org metadata, the Creative Work object has a license property which may be a URL.

3. To indicate that such a used link is definitely a link to a resource expressing a license the Web Linking RFC 5988 should be used. In its section 6.2.2. Initial Registry Contents many relationships of a URL are defined, one of them is "license". The information I've found about this Web Linking RFC does not include a relationship to a specific format of such a resource. And HTML5 defines for the link element only these attributes: href, rel, media, hreflang, type and sizes. Nothing like "format".

4. Sorry @csarven, but I can't get your last lines. In the example you show how the relationship of the asset https://example.org/foo to the ODRL policy https://example.org/foo.odrl can be expressed.
   What do you mean by "the discovery of a resource that may hold all ODRL information about the associated resource." Do you implicitly mean that the ODRL policy https://example.org/foo.odrl does not hold all information? ODRL support inheritance relating two or more policies, other relationships between policies are not covered.
   And what about "discovery through the HTTP header would allow the consumer to get further details about the target."? What HTTP header do you mean, the one linking to the asset/target or the one linking to the ODRL policy?

[simonstey]

@nitmws

Sorry @csarven, but I can't get your last lines. In the example you show how the relationship of the asset https://example.org/foo to the ODRL policy https://example.org/foo.odrl can be expressed.
What do you mean by "the discovery of a resource that may hold all ODRL information about the associated resource." Do you implicitly mean that the ODRL policy https://example.org/foo.odrl does not hold all information?
ODRL support inheritance relating two or more policies, other relationships between policies are not covered.

Well, how does one know whether foo.odrl holds all relevant ODRL infos about a respective resource without checking each and every policy linked in any of the available <https://example.org/foo> <http://purl.org/dc/terms/rights> <policy> . triples?

e.g.,
first.ttl

<https://example.org/foo>
   <http://purl.org/dc/terms/rights> <https://example.org/foo.odrl> .

<https://example.org/foo>
   <http://purl.org/dc/terms/rights> <https://example.org/foo2.odrl> .

second.ttl

<https://example.org/foo>
   <http://purl.org/dc/terms/rights> <https://example.org/foo.odrl>, <https://example.org/foo3.odrl>, <https://example.org/foo4.odrl> .

the question is less about first.ttl + second.ttl = ? but more about how to tell a consumer/agent/... to read both first.ttl AND second.ttl for fetching all relevant ODRL policies for <https://example.org/foo>

And what about "discovery through the HTTP header would allow the consumer to get further details about the target."? What > HTTP header do you mean, the one linking to the asset/target or the one linking to the ODRL policy?

I reckon @csarven was referring to something along the lines of what's discussed here https://solid.github.io/web-access-control-spec/#acl-resource-discovery

- simon

[csarven]

Thanks @simonstey . Yes, along the lines of an ACL resource associated with a resource.

@nitmws I meant the Link HTTP header as per the examples. The relation type would preferable be a URI to get more mileage out of it ie. easily usable on the interaction and data layer, and doesn't need to be registered with IANA. It'd simply be defined by the ODRL vocab.

---

What's sought is about discovering a resource containing ODRL information that's associated with a resource. There is no strict expectation that the ODRL resource must contain all ODRL data about the resource. The controller (publisher) of the resource decides.

I would say the property that I'm looking for to help with discovery is similar to PROV-O's http://www.w3.org/ns/prov#has_provenance :

Indicates a provenance-URI for a resource; the resource identified by this property presents a provenance record about its subject or anchor resource.

(I used http://www.w3.org/ns/odrl/2/rights in my earlier example as a general term as opposed to a narrow notion of "rights" in context of ODRL.)

So, a property - just to illustrate the idea - like http://www.w3.org/ns/odrl/2/has_odrl can be used to address the use case on helping consumers of a resource discover ODRL information that's associated to it.

I would add that this relation does not need to (and probably should not) mandate that the ODRL resource must include certain or complete information. Surely the best practice would be that the associated ODRL resource contains "useful" information about the resource.

There are other properties out there with the same general idea. Perhaps the IANA describedby link relation:

Refers to a resource providing information about the link's context.

For a bit more detail from Linked Data Platform's update to describedby at https://www.w3.org/TR/ldp/#link-relation-describedby :

The relationship A describedby B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.

---

Aside: In the W3C Solid CG ( https://www.w3.org/community/solid/ ) we are looking into how to incorporate ODRL in the Solid ecosystem eg. solid/specification#151 , solid/specification#116 . Having this property (URI) defined by the ODRL vocab can pave the way for easy interop. Alternatively, we can add a property to the Solid Terms ( http://www.w3.org/ns/solid/terms ) but I think id be best for ODRL to take this on... for obvious reasons.

[nitmws]

I think this "finding all ODRL policies relevant for a resource/target" is an issue a bit outside the scope of ODRL because how to solve that depends a/ on how rights expressions/licenses are created and applied by the assigner and b/ on a metadata standard applied to a type of resource/target. (Sorry, but still I consider metadata standards for assets as relevant as they define a vocabulary for the communication between quite different parties.)

I see these options - and let's assume the ODRL-assigner is the party responsible for creating and applying ODRL policies:

1. The assigner sets as strategy "any rule applied to a specific (group of) target asset(s) reside in a single policy". Associating this policy with the asset is sufficient.

2. The target asset may have multiple assigners with their individual ODRL policy/ies - and they exist side by side.
   A well known use case for that are photos: a photographer takes a photos and offers it on different markets (e.g. Europe, North America, Asia, ...) by different photo agencies = assigners. And it is quite typical that e.g. a licenses from the European photo agency includes the constraint "can only be published by a European publisher".
   This case raises the question: is it a real need to get access to all ODRL policies applied to a photo worldwide? (I hear some "nos" swirling around.)

3. The assigner sets as strategy "multiple ODRL policies may apply to a single target asset - and I help customers to find them". This help for customers could be a metadata standard applied to an asset allowing multiple links to licenses, or it could be a single link and resolving it a list of all ODRL policy links relevant for this target asset are returned.

This option raises the question "should the ODRL specs help with that"?
One option for applying more than one policy is to add a property like "seeOtherPolicies" which may have multiple values. By our experience at IPTC this does not work well in practice: a policy with "seeOtherPolicies" and 5 values is issued on 10 January 2021. On 20 January 2021 a new policy regarding the same target asset is issued - and the seeOtherPolicies of all other 6 policies must be updated.

Another option is to define an abstract umbrella - or let's call it an ODRL policy collection. Its data model covers only having a role and a list of identifiers of existing ODRL policies. The value of the role could be "all policies covering the same target asset" but others as well, e.g. "all policies covering the same assignee".

Response to @csarven 's comment, just coming in: I guess my suggested ODRL policy collection is quite close to the provenance record.

Michael

[csarven]

@nitmws , thanks. If the proposal here is sufficiently clear, is there a process to take further? A review of the proposal in an upcoming CG meeting?

[nitmws]

@csarven first asking you: goes my proposal in the right direction? In this case I would create a new issue with a specification draft. This can be discussed at upcoming ODRL calls.

Regarding next steps: ODRL 2.2 is a W3C Recommendation, therefore it is impossible to change it without a Working Group established by W3C. But the CG could work on a specification draft, test it ... = make it ready for formal adoption.

[csarven]

I admit that I'm not entirely clear about your proposal or at least how it differs from what I've originally proposed ie. odrl:has_odrl being similar to prov:has_provenance . The domain and range of this property is a URI , a rdfs:Resource (implied) in terms of RDF, if you will.

I would like to mention another related use case here on having an independent "ODRL resource" (again, what information goes in there is decided by the controller/publisher): the lifecycle of an ODRL resource may be dependent on the lifecycle of the resource that's referring to it. For example, re: foo odrl:has_odrl foo.odrl, if foo gets deleted, system may need to delete foo.odrl as well. This is conceptually simple resource management.

Thanks for creating a new issue / spec draft and willing to take it up in an upcoming call! I'll make sure to be present.

It is possible to add terms to existing namespaces, see https://www.w3.org/2016/08/namespaces/#adding with or without spec reference in both WGs and CGs. Related case: addition of the ldp:inbox property (under the LDP namespace based on the need of the LDN spec: https://www.w3.org/TR/ldn/ ).

[nitmws]

I'll try to sort out the issues @csarven has raised and provide comments and a spec draft:

A) Referring to an ODRL Policy: this is already available. There is an odrl:hasPolicy property/predicate in the ODRL namespace: https://www.w3.org/TR/odrl-vocab/#term-hasPolicy. A has_odrl would compete with this property, different semantics are needed, see below hasPolicyCollection.

B) re lifecycle: it may be the case that his issue can be covered by the ODRL Temporal Profile: https://w3c.github.io/odrl/profile-temporal/ with a list of requirements: https://www.w3.org/community/odrl/wiki/ODRL_Temporal_Profile_Requirements
(see also the Notes of the ODRL call on 2 November 2020 - https://lists.w3.org/Archives/Public/public-odrl/2020Nov/0000.html)

C) Spec - first draft
This spec draft is based on ODRL 2.2 RDF/Turtle serialization - https://www.w3.org/ns/odrl/2/ODRL22.ttl

:PolicyCollection
    a rdfs:Class, owl:Class, skos:Concept;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Policy Collection"@en;
    skos:definition "A set of one or more ODRL Policies, they may be collated for a specific purpose"@en .

:includesPolicy
    a rdf:Property , owl:ObjectProperty, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Included Policy"@en ;
    skos:definition "Identifies an ODRL Policy which is included into an ODRL Policy Collection."@en ;
    rdfs:domain :PolicyCollection ;
    rdfs:range :Policy .

:collectionPurpose
    a rdf:Property , owl:ObjectProperty, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Policy Collection Purpose"@en ;
    skos:definition "Identifies which purpose drives the collection of ODRL Policies."@en ;
    rdfs:domain :PolicyCollection ;
    rdfs:range :CollectionPurpose .

:CollectionPurpose 
    a rdfs:Class, owl:Class, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    skos:definition "A purpose for a collection of ODRL Policies."@en ;
    rdfs:label "Policy Collection Purpose"@en .

:sharedAsset
    a :CollectionPurpose, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Shared Asset"@en ;
    skos:definition "A Policy Collection for which the identified Asset is the target Asset of all the Rules of the included ODRL Policies"@en ;
    skos:scopeNote "Example"@en .

:sharedAssignee
    a :CollectionPurpose, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Shared Assignee"@en ;
    skos:definition "A Policy Collection for which the identified Assignee is the Assignee of all the Rules of the included ODRL Policies"@en ;
    skos:scopeNote "Example"@en .

:hasPolicyCollection
    a rdf:Property , owl:ObjectProperty, skos:Concept ;
    rdfs:isDefinedBy odrl: ;
    rdfs:label "Target Policy"@en ;
    skos:definition "Identifies an ODRL Policy Collection which is relevant for the identified Asset or Party."@en ;
    rdfs:domain [
        a owl:Class ;
        owl:unionOf ( :Asset :Party ) ;
    ];
    rdfs:range :PolicyCollection .

Quick summary following the raised need:

• An asset/resource may have an odrl:hasPolicyCollection, targeting an instance of PolicyCollection
• An instance of Policy Collection must include at least one ODRL Policy, using the odrl:includesPolicy
• An instance of Policy Collection may include an odrl:collectionPurpose, defining what purpose drives this collection.
• A Policy Collection with odr:sharedAsset should cover the raised need to provide a set of all the ODRL Policies having a specific Asset as target Asset.

[riannella]

My brief comment is that we have defined the odrl:hasPolicy property: https://www.w3.org/TR/odrl-model/#policy-has for this purpose.

And this has been adopted by DCAT: https://www.w3.org/TR/vocab-dcat-2/#Property:resource_has_policy

[csarven]

Thanks @nitmws @riannella . I think I now better understand your suggestion involving odrl:hasPolicy. I agree that is fairly close to what I've inquired in this issue and can indeed be used towards this purpose. Same goes for the proposed odrl:hasPolicyCollection.

FWIW, there are some key differences to what's intended with odrl:has_odrl:

An "ODRL resource" can potentially be self-contained or -containable information. It is intended to be an atomic resource describing the ODRL information specific to the target resource. So, a property like odrl:has_odrl leaves it open as to which ODRL Classes (and properties) can be used in that resource.

Whereas the target of odrl:hasPolicy is an instance of odrl:Policy. This may be still workable eg:

HEAD https://example.org/foo

200
Link: <https://example.org/foo.policy>; rel="http://www.w3.org/ns/odrl/2/hasPolicy"

And when we GET https://example.org/foo.policy it could include:

<>
  a odrl:Policy , odrl:Offer ;
  odrl:target <https://example.org/foo> ;

  odrl:permission [
    odrl:action odrl:archive ;
    odrl:assigner <https://csarven.ca/#i>
  ] .

Because the base URL is intended to be the Policy, we have to refer to other instances of classes through fragments, bnodes or external resource. For the example above, bnode seems reasonable.

For simple resource lifecycle management by the server, it'd be easier for clients that are writing the policy to use bnodes. This may need to be a shared agreement between clients and servers. It'd be possible to use an external IRI for the target of odrl:permission but then the system needs to take additional steps:

• creating a self-describing dereferenceable resource for that specific permission eg. https://example.org/foo.permission;
• handle two (or more) displays of the permission block eg. in https://example.org/foo.policy as well as in https://example.org/foo.permission.

This may appear to be nitpicky but we can contrast that with the generic ODRL resource case (similar to prov:has_provenance or describedby or acl relation for discovery) where the base URL would be a Web resource and the client can attach whatever is needed to fragments.

Hence, resource description and lifecycle is notably different for odrl:hasPolicy and odrl:has_odrl.

[joshcornejo]

We spoke about this today - my 5 cents:

odrl:Asset has the odrl:hasPolicy

DCAT ( https://www.w3.org/TR/vocab-dcat-3/ ) already references odrl and has a set of definitions for different types of assets.

You can then build and end up with:

ex:AnAsset   a odrl:Asset, dcat:Resource;
             terms:created "1970-01-20T18:33:42.4440000Z"^^xsd:dateTime;
             terms:description "some description"@en;
             terms:valid ex:URI_range;
             odrl:partOf ex:AncestorAsset.
ex:URI_range a time:ProperInterval;
             time:after "1970-01-20T18:33:45.1230000Z"^^xsd:dateTime;
             time:before "2100-01-20T18:33:46.0860000Z"^^xsd:dateTime.