Open RinkeHoekstra opened 9 months ago
At this point, it is difficult to impose to publishers to make this URL dereferencable. It would be still another constraint to maintain, on a website that may be managed by a third party. It is not certain that assets protected by a specific target are all in the same tree structure. And in case of dispute, what would be the effect of a http error 404?
Reading again the ODRL 2 spec: target
is an Asset or an AssetCollection.
It can be the URL of an individual asset (-> dereferenceable), or it can be node, i.e. a reference (URI) or a json object, which can be an asset or collection on assets with a uid
and a source
(which is also a URI, dereferenceable or not). Complex.
We added target
in our ODRL profile so that a content provider can offer different permissions for different types of assets. This was added with extensibility in mind, but with no precise use-case.
As this ODRL structure is not protecting access to content (tdm-reservation is the proper tool for this), but a way to indicate which kind of licenses a rights owner can provide (this is an indication, a helper), the best course of action could be to simply remove target
from our ODRL profile. At least for the current year, until a clear use-case appears.
If the
target
of a rights statement (e.g. a permission) is not dereferenceable, it is unclear what this identifies. ODRL is also quite opaque about how the identifier of an Asset or AssetCollection is linked to the actual artefacts.How can we ensure that a
target
statement is robust enough to stand through a dispute? Are we adopting the URL semantics and saying: anything hosted under this URL and its children?https://github.com/w3c/tdm-reservation-protocol/blob/a1e0c76ac2cc9da602a8f916951c70a4c33b6b18/spec/index.html#L517-L524