Review Comment:
Unfortunately, the matching algorithm seems actually wrong, in the light of the authors' reply. Please fix it as explained below, and let me have a quick look at the new version before publication.
DETAILED COMMENTS:
The explanation R3.2 provided by the authors clarifies that their matching algorithm is correct in some cases. Still, there are cases where it returns a wrong answer.
1) prohibitions:
if offer:spatial is EU and request:spatial is Spain then the algorithm does not reject the request, because it checks whether EU is contained in Spain (which is false). However, a prohibition concerning the EU should cover also Spain, and block the request.
Note that swapping the two terms of the equivalence (i.e. checking whether request:spatial is a special case of offer:spatial) would not solve the problem: if offer:spatial is Spain and request:spatial is EU then the algorithm would not reject the request because (due to the swap) it would see that EU is not a special case of Spain (again). However, the prohibition applying to Spain should block a request that is meant to apply to *all* Europe (in other words, the request is too general, given the prohibitions in the offer; the request includes also forbidden types of data usage).
The correct solution is rejecting the request whenever request:spatial and offer:spatial have common elements (nonempty intersection). As a special case, this happens whenever one of the two terms is a special case of the other, as in the above examples. The rationale is that prohibitions may block the request by denying it either totally or *partially*.
The same considerations apply to the other properties of offers and requests checked in lines 31-36. In particular, purposes are organized in a hierarchy in DPV.
2) permissions:
I understand that offer:group and request:group are classes of entities. In order to permit a request, the group of entities involved in the request should be *entirely* contained in offer:group (otherwise the request involves some entities that are not authorized to use the data).
This means that the check between lines 44 and 45 should verify whether request:group is not a subclass of offer:group (i.e. the two terms should be swapped).
Similarly for the test on purposes between lines 45 and 46.
Another problem is that the symbols used in the algorithm are misleading and confusing in various ways:
- the standard semantics of the membership operator \in is: "the left-hand side is an instance of the class in the right-hand side", while here it is mapped on owl:sameAs which means "the lhs and the rhs are the same thing". Note that \in is asymmetric while owl:sameAs is symmetric.
- the standard semantics of the equivalence symbol \equiv is that its two terms denote the same class, while here it is mapped on owl:subClassOf which means: "the lhs is included in (and possibly differs from) the rhs". \equiv is symmetric, while owl:subClassOf is antisymmetric.
Thus, in order to improve readability and prevent misunderstandings, the authors should replace \in with "=" and \equiv with \subseteq in the algorithm.
| 
