Should we merge the file on the origin server with the ODRL TDM Policy?

[llemeurfr]

Looking at the similarities between the structure obtained in the Proposal for Policies as ODRL 2.2 structures and the Proposal based on a file hosted on the origin server, we could decide to merge both.

In such a case, the target URL must point to the folder containing every resource associated with this Policy and pattern matching must be allowed: this is a departure from the RDF purity of ODRL. Or the target must become an AssetCollection object with a source property representing the path: pure but more verbose.

[RobinLeMaroisSeraphin]

Arguments against the merging of the file and the policy : (i) Standard attractiveness : a simple file may interest those who want to use "TDM-a = "0" without having to deal with the more complex policy, thus helping the spreading of the standard. (ii) Potential complexification of the policy : a simple file may be more practical for users in case the policy takes more and more elements into accounts making it potentially quite complex.

[claudiotubertini]

Adding more and more specifications (headers, html meta-tag, single file, odrl) is not something that helps simplicity. It increases the steepness of learning to use the standard. For this reason I believe that might be better to merge at least the two solutions that make use of json files. I think the simplicity for publishers that stick to tdm-a=0 is not a concern, simply they will not do anything and the exception will do all the work. TDM machine reading standard regards publishers that want to add a new licensing activity to their business. Therefore they have to express the details they need, may be only a contact phone number, if they are in a joking mood. And ODRL has the expressiveness to solve all the problems at once.

[llemeurfr]

From the minutes of June 1st meeting: The current comments do not allow to reach a consensus. During the dicussion it appears that the participants to the call are in favor to keep separate both structures, as it keeps a clean separation between the core deliverable of the group (related to the Article 4 of the DSM) and the optional & advanced feature (offering TDM Policies). The final choice will be done during the next meeting.

[llemeurfr]

This issue has not been discussed during the summer and it appears that the group is fined with keeping a clear separation between the required technique based on a file hosted on the origin server, which is basic, and the more complex but optional TDM Policy structure.

I'll therefore close this issue.