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.
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:
permission
/ target
).permission
/ target
.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.
A permission MAY be completed with a geographical constraint.
This profile uses one value from the ODRL Vocabulary for the leftOperand
:
spatial
creates a constraint on a geographical location of the TDM Agent.This profile uses one value from the ODRL Vocabulary for the operator
:
isPartOf
indicates that a given value is contained by the right operand of the constraint.This profile defines the possible values of each item of the rightOperand
, expressed as an array:
urn:iso:3166:
followed by a 3 letter code designates an iso3166 3 letter country code.Notes: