Review Comment:
The paper describes a model for describing Normative Provisions, and reasoning over those. The approach attempts to address the problem of modeling complex legal texts, while staying within the OWL-DL expressiveness. Previous approaches apply different kinds of rule languages to perform similar reasoning, while this approach instead uses only OWL-DL (or OWL 2 DL, I assume, since the authors make extensive use of the punning feature and are hence using OWL 2). The paper is clear and well-written, but has some shortcomings, mainly in three areas, namely motivation, implementation and evaluation.
Although the author clearly states that the goal is to stay within OWL-DL it is not entirely clear why this is desirable. Apparently others have built systems using rules instead, why is that not appropriate for this particular case? The author should make it more clear why this approach is different, or rather why it *needs to be* different, i.e., what is the motivation for creating an alternative approach to the rule-based ones that are referenced?
When considering the implementation of the approach, the author describes the implementation only in terms of knowledge representation, reasoning and querying. However, a large part of the task would be to actually go from the XML markup shown at the beginning of section 5.1, to the RDF triples shown at the very end of that section. This is not a straight-forward step, at least not if intended to be performed automatically. Performing it manually is of course an option, but as far as I understand legislative text can be quite extensive, and hence manual translation to RDF seems to be infeasible or at least impractical. Rather, one should probably make use of the existing XML markup, and make an (semi-)automatic transformation of that markup into RDF. Many approaches for XML to RDF transformation exists, and the author should (in case this is not already implemented) at least add a discussion on how such approaches could be used to automate the transformation. A starting-point for the discussion is given by the author in the second-to-last paragraph of the conclusions section, however, here the author focuses on the need to have the XML markup in the first place, but does not properly acknowledge the problem of going from XML to RDF.
Concerning the third issue, i.e. lack of evaluation, the author provides some examples to show how the populated models may be used, which is very useful, but does not put this into a larger context, nor does the author provide any evidence of how well it actually works. Examples are good in order to illustrate and explain the solution, however, I would suggest that the author at least also adds a discussion on the actual context where this will be used, e.g., outlining some real system where this is going to be used by legal practitioners. Preferably, this would be done in terms of a real case study, however, even a mere discussion would improve the impression of the paper. As it is now, the author should not use the term "case study" to describe the examples, which still occurs at the beginning of section 5.
Additional comments:
It is very nice that that paper includes links to both the Provision Model and the domain ontology about consumer law. However, the examples in the paper do not conform to the actual models. For instance, Supplier is not a class in consumer-law.owl, instead it is named supplier (non-capital S). Similarly the class ContractualTerms is actually called contractual_terms. Such mismatches make it hard for the reader to find and inspect the actual class in the model. In addition, although this is not strictly part of the paper, I would propose to "clean up" the consumer-law.owl ontology, especially if this is actually modelled by the author. The OWL model feels quite sloppy, especially in terms of its lack of naming conventions and limited use of best practices. For instance, some classes are named using plural forms, such as "activities". While this name indicates that instances of this class would be groups of activities, the names of subclasses (such as commercial_activity and offer) on the contrary seems to indicate that instances will be single activities, and reading out their relationships, e.g., "commercial_activity is a kind of activities", makes no sense. Capital letters are frequently mixed with non-capital letters, e.g., "object" being a superclass of "Physical_Object", and underscore (_) is frequently mixed with a dash (-). When designing an ontology, it is common to try to adhere to best practices and to decide on some naming conventions before you start. Common naming conventions that could be considered include: starting all class names with a capital letter (to distinguish them from individuals and properties when they are used), using singular forms for class names unless the class actually will have groups as individuals, deciding on a uniform way to handle the lack of spaces (e.g., *either* using underscore, dash, or the camel convention). Also, in the ProvisionModel.owl there seems to be a small error, i.e. Liability lacks the unionOf-statement.
I would also be interested to hear why the author has chosen the current modeling approach, in particular concerning the use of the OWL 2 meta-modeling features (e.g., using so called punning) for expressing RDF triples about the legal statements? The author states that the range of all the properties that express attributes of, for instance, rights or liabilities, is owl:Class, meaning that any RDF triple expressed for a specific right-instance will have as attribute values instances of owl:Class, hence, classes and not individuals. While this modeling works fine in OWL2, I am still curious as to the motivation for it, when one could also have expressed those classes in question as individuals populating the domain ontology.
Another modeling consideration is connected to the example in section 7. This example seems to indicate that there are no explicit relations between duties and procedures, why is that the case? If I understand the example correctly, one has to use the implicit knowledge that the same configuration of attribute values will retrieve the related instances when writing the query, rather than letting this be inferred explicitly by the model. Is there a motivation for this, it seems not to be the best solution to me?
Finally, the notation used in the paper is not entirely clear. The author mixes screenshots from some ontology editing tool, with RDF/XML excerpts, and some kind of DL notation. Preferably the author should reduce the number of different notations, and for each notation that is used, the author needs to either explain the notation or refer to some source where it is explained, so that a reader that is unfamiliar with the notation can easily look up the details.
Minor details:
* on page 1: "willing to subscribe a" - > "willing to subscribe to a" and "pre-condition" -> "pre-conditions"
* on page 2, second column: "well expressed by Rawls" - is Rawls the name of an author of some related work? Please add citation.
* first paragraph of section 3: "Two kind" -> "Two kinds"
* the relation labels in Figures 4-6 are unreadable when printing the paper in B&W
|
