Enhancing Data Use Ontology (DUO) for Health-Data Sharing by Extending it with ODRL and DPV

The authors have reviewed the paper, enhanced its clarity in various sections, and added examples. Table 1 has been revised and typos fixed, while the matching algorithm at p. 13-14 has been illustrated.

The paper has been improved in this new version.

However, my specific comments seem not being addressed.

In particular, I suggested:

"Things to improve include:
- Table 1 is not fully comprehensive.
- Evaluate the effort needed in non-directly mapable concepts and how useful they are.
- Define the updated ontology as such."

Concerning the first suggestion, although being mentioned in the cover letter, no changes have been done. It is clear what the intention of the table is, but explaining the meaning of the different columns would help.

The other 2 comments seem to be ignored. I would appreciate an explanation of why there is no need to change anything on those.

The authors have addressed my comments satisfactorily. Only (hopefully) minor modifications are needed:

1 - the meaning of one phrase is still unclear to me;
2 - some of the conditions in Algorithm 1 may have to be refined/corrected;
3 - the new text contains some typos.

Concerning point 2, I would like to have a quick look at the new version before publication, because the matching algorithm might be wrong.

Detailed comments:

1) On page 5, line 11 the sentence "where the concepts to be matched in a policy are pre-determined" is unclear to me. Does it refer to DUOS or to [19]? The former is correct, the latter would not (because [19] is vocabulary-agnostic).

2) IMHO if a prohibition denies data usage with some spatial condition SC1 (eg Ireland and Germany) while the data request wants to use the data with another spatial condition SC2 that *overlaps* SC1 (eg Ireland and France), then the answer should be DENY. This is because a GRANT decision permits data processing using SC2, that includes also forbidden spatial conditions (Ireland). On the contrary, Algorithm 1 would not DENY the request because SC1 and SC2 are not equivalent (line 30).

Similarly, the request is denied only if offer:purpose is equivalent to request:purpose (line 36), but it should also be denied if the two purposes ovelapped (eg when request:purpose is a subclass of offer:purpose).

Dually, for permissions, the request is denied whenever offer:purpose is not equivalent to request:purpose (line 46), but the request is acceptable if request:purpose is a subclass of offer:purpose.

In other words, according to my understanding of the matching process - and without the help/guidance of a formal semantics for the policy language - the current matching algorithm seems wrong.

3)

Page 2, line 36: permissible -> permitted (?)

Page 3, line 8: the sentence "[ODRL] is *the* W3C standard [...] to model rules and policies" sounds too strong to me; please consider that there exist also W3C rule languages such as SWRL and RIF. I would write that ODRL is *a* W3C standard...
As a side note, also the OASIS standardisation organisation published policy languages such as XACML and Legal RuleML.

Page 18 lines 48-49: the sentence "the extent of what and how they wish to utilise our suggestions" sounds weird, it may be better to reorder it (eg what to utilise and how).

Finally, in my previous review I forgot to suggest to add a reference for "sticky policies" on p.2, line 33.