tdm-reservation-protocol

Dealing with TDM Policies

Status of this document

This is a best practices document, its aims is to help implementors handling with TDM Policies and it may evolve over time.

The related section of the specification is Expressing a TDM Policy.

How TDM miners should identify the content they want to mine?

An issue TDM Actors are facing is that when scrapping a server, TDM Agents will retrieve large series of resources for which TDM Rights are reserved and a TDM Policy is set.

If the policy states that consent must be obtained, it would be illogical to send an email for each and every resource the TDM Actor is willing to mine. The good thing is that TDM Policies have a URL which is a first mean to de-duplicate such requests, and a permission / target property as a second mean to achieve optimal de-duplication (several Policy URLs could reference the same target).

Reminder: the mandatory target of a permission is a URI identifying the collection of resources involved in the policy.

TDM Agents will use the value of this target property in their messages to publishers, to identify a collection of resources they wish to mine. This identifier shall therefore properly identify a specific collection of resources and be well know from their publisher.

The process a TDM Agent follows can be:

Note: The target value is not necessarily dereferencable. Accessing this URL may end with an http error (403 in many cases): this is not a processing error.

Possible extensions

Constraints on geographical areas

A permission MAY be completed with a geographical constraint.

This profile uses one value from the ODRL Vocabulary for the leftOperand:

This profile uses one value from the ODRL Vocabulary for the operator:

This profile defines the possible values of each item of the rightOperand, expressed as an array:

Notes: