search

w3c / tdm-reservation-protocol

Repository of the Text and Data Mining Reservation Protocol Community Group
https://www.w3.org/community/tdmrep/
Other
7 stars 8 forks source link

tdm property values in case of protocol errors #20

Closed llemeurfr closed 2 years ago

llemeurfr commented 3 years ago

The new version of the draft specification considers that if there is a protocol error, tdm-reservation is considered unset. In this case the TDM Agent will act as if the rightsholder had not provided any information.

A previous version was considering that the value of tdm-reservation was "1" in such a case. This was rised as an issue during a previous call.

The choice will be finalized during the next meeting.

llemeurfr commented 3 years ago

This issue was discussed during a meeting. No consensus was found so far.

llemeurfr commented 3 years ago

This provision of the specification is a concern for Giulia, especially when tdm-reservation = 2 but tdm-profile is not set. Because tdm-reservation indicates the "tdm rights are reserved and a policy is available" she considers the if tdm-profile is missing (or unreachable), the TDM Actor must consider that tdm-reservation = 1.

This leads to re-discuss if the value 2 of tdm-reservation is really needed, cg issue #23.

giuliamarangoni commented 3 years ago

Thank you Laurent, I try to better explain my view on issue #20

As the main goal of this Community group is to specify a machine-readable solution to express TDM reservation in line with the EU DSM directive, I think that in presence of a TDM reservation message containing errors the most cautious and safer interpretation to be applied is that the rightsholders has reserved its rights (i.e. tdm-reservation equals 1). Otherwise, the TDM agent would risk to mine a content for which rights are reserved, with possible legal implications. In other terms, I think that in presence of the metadata structure for TDM reservation, tough with inconsistent values, it is never possible to assume that TDM rights are not reserved.

The need for such interpretation is particularly evident for me in the case described in Par. 5.2 tdm-policy. According to the current specs, the absence of tdm-policy when the value of tdm-reservation equals 2 (TDM rights are reserved and a TDM Policy is available) is a protocol error that should be interpreted as tdm reservation is unset. This would mean that the absence of an optional feature of the TDM reservation protocol (i.e. to communicate if a license is available, in addition to the information that rights are reserved) would invalidate the core message feature conveyed by the protocol (i.e. the communication that rights are reserved).

Therefore, I propose to reconsider the handling of protocols error by restoring the approach that was considered in the early discussions of this group, i.e., in case of protocols error, to adopt the more cautious and safer interpretation of the message, thus adopting the default value TDM reservation=1 (and not TDM reservation=unset)

In detail, this implies that:

1) Par. 5.1 tdm-reservation. In case of protocol error, the TDM Agents should consider that tdm-reservation is 1 (TDM rights are reserved).

2) Par. 5.2 tdm-policy The absence of tdm-policy when the value of tdm-reservation equals 2 (TDM rights are reserved and a TDM Policy is available) is considered a protocol error. In such cases TDM Agents should consider that tdm-reservation is 1 (TDM rights are reserved)

3) Par. 5.2 tdm-policy [..] If the Web resource located at this URL is a Web page (i.e. its content-type is text/html), this resource is considered human readable. If it has the content-type of the TDM Policy (i.e. its content-type is application/ld+json), this Web resource is considered machine-readable. Other content-types are considered protocol errors. In such a case TDM Agents should consider that tdm-reservation is 1 (TDM rights are reserved)

4) 6.1 TDM File on the Origin Server Not sure to understand this case, concerning the matching of URL patterns as it is very technical. My guess would be that all protocols errors should be treated in the same way (thus also here, if no match is fond, a TDM agent should consider that tdm-reservation is 1) but we may need to further discuss it.

This said, as Laurent reported under issue #23, I also suggested that if no consensus can be reached in the group on issue#20, it may be considered to remove value 2 from tdm-reservation. This would reduce the cases where consistency checks between TDM-Reservation and TDM-Policy element are needed. In particular, the protocol error described at point 2) above wouldn’t happen anymore. However, there would still be the issue of the value to adopt for the protocols errors described at point 1, 3, 4. That I think should be further discussed for the reasons I tried to explain above.

llemeurfr commented 2 years ago

Now that tdm-reservation value 2 has been removed, this issue seems moot. The only remaining protocol error is a value of tdm-reservation different from 0 or 1. In such a rare case, considering that tdm-reservation is unset is still the only good solution imho.