Participants: Brendan, Giulia, Laurent, Claudio, Jean-Baptiste, Steve
In previous meetings, the group has worked on what TDM means in practice, the vocabulary to be used during the project, the goals and requirements for a technical solution, the creation of several use cases. They have also compiled a set of past and existing initiatives with a similar scope.
Then, the group discussed on how rightsholders can declare to TDM Agents the reservation of TDM Rights. Three different technical solutions were selected: one based on http headers, another based on a file hosted on the origin server, and a third based on html meta tags. These three solutions correspond to different situations and technical skills. The priority in which these techniques should be processed by TDM Agents is still to be decided.
Using one of these techniques, a rightsholder can express either that “TDM rights are not reserved”, “TDM rights are reserved” or “TDM rights are reserved but a TDM license can be acquired”.
In the latter case, it is interesting for both parties (rightsholder and TDM Actor) to create a machine readable TDM policy which details in which conditions a TDM license can be acquired”.
Defining what such TDM policy will be is the new task of the group.
Agenda: Presentation of RightsML as an ODRL use case; TDM policy properties.
Brendan (IPTC) presents RightsML.
RightsML is a “profile” of ODRL. “Policies” are related to time, geography and media distribution channels. RightsML 2.0 is based on ODRL 2.2 (the latest version).
See dev.iptc.org for RightsML samples.
ODRL is expressed in RDF and can be serialized in RDF/XML, JSON-LD or Turtle. To understand ODRL, we should start with the ODRL 2 Core Model. The “ODRL Profile Best Practices” gives hints on how we can build a TDM profile.
People can express “permissions” and define “duties” like “payment” or “attribution”. Constraints can be combined. “tickets” and “offer” are used when no “assignee” is known in advance. Possible “actions” are “derive”, “transform”, “translate”, which fit with TDM usage. Possible “contraints” are “payment”, “geospatial …” …
We could create a profile of ODRL, with a very limited set of possible actions and constraints.
It would be versioned, so that new features can be added over time and we could follow the evolution of the ODRL spec.
Q. Who is part of the ODRL group today? It is a Community Group. Renato Iannella (Monegraph) is still the guide. A core half a dozen people works of it.
Q. Is RightsML successful? RightsML has some level of uptake now. e.g. Reuters is using it. It took time… Most newspapers don’t parse RIghtsML and rely on the old fashion textual expression of rights.
Q. Are there ready to integrate software able to process ODRL? Some proofs of concept. IPTC has developed one in Python. Reuters did their own implementation.
Q. Were there some collaboration with Google? IPTC didn’t talk about RightsML with Google.
Giulia presents TDM license properties
The document was drafted from information received from participants, especially Steve from Elsevier.
Types of assignees can be commercial, non-commercial organizations, information scientist.
Elsevier is using the term “authorized users”, i.e. users authorized to apply TDM on content in a given company.
“use case” is about the kind of usage – create a knowledge graph, extracting trends … but to describe it is a machine readable langage can be difficult, because concepts are nuanced.
“data types” is about XML, PDF ….
“License data” copyrighted material, e.g. XML content, “derived data” is e.g. an index built upon XML content.