Action 106: Detailed review of the Fragments Proposal

Hi Boris and Bernardo,

Thanks again for putting together the Fragments Proposal document. As I 
mentioned during the last meeting, I would love to see a version of this 
document that would be more self-contained and would not assume that the 
reader is already familiar with the functional syntax of the whole OWL 1.1 
language. I will start working on such a version this week, and, as Bijan 
suggested, it could be added as an appendix to the current document.  In 
the meantime, please find here a detailed review of the current proposal. 
This review was done in fulfillment of the first part of Action 106 
(review of the Fragments document).

==========================================================
DETAILED REVIEW:

Section 1: Introduction

1)      The reference to the nonstructural restrictions on axioms is 
incorrect. It should be "section 10" instead of "section 6". In general, I 
wonder if our wiki has a mechanism to make more stable references to 
sections of a document. If it is the case, we should use it. 

Section 2.1: EL++ feature overview:

2)      In the list of supported features, there are a lot of omissions of 
the "data" aspect of most EL++ features: DataSomeValueFrom, DataHasValue, 
DataOneOf, SubDataPropertyOf, EquivalentDataProperties, 
DataPropertyDomain, DataPropertyRange
3)      In the list of supported features, under the "facts" category, the 
following categories of facts are not mentioned: ObjectPropertyAssertion 
and DataPropertyAssertion
4)      The list of non-supported features has the same kinds of omissions 
of the "data" aspect of non supported features as in 2).

Section 2.2 : Fragment specification

5)      In the first sentence of this section,  the reference to "section 
6" should be replaced by a reference to "section 10" as in 1)

Section 2.2.3: Classes

6)      In the first sentence of this section, the DataMaxCardinality, 
DataMinCardinality and DataExactCardinality should be added to the list of 
disallowed features.

Section 2.2.4: Axioms

7)      "objectPropertyRange" is mentioned in the list of 
"objectPropertyAxioms". However, the paper "Pushing the EL envelope", 
which is referenced as the theoretical foundation of EL++, does not have 
range as one of the features of EL++. I understand that, in Carsten?s 
paper "Pushing the EL Envelope Further" submitted to OWLED,  EL++ is 
extended to support range.  I think we should also have a reference to 
that paper if we want to keep objectPropertyRange and dataPropertyRange in 
our EL++ fragment.

Section 3.2.1: DL-Lite Classes

8)      Adding "objectIntersectionOf" in the production of "superClass" 
should be harmless.

Section 3.2.2: DL-Lite Axioms

9)      The last paragraph of this section starts with "Finally, DL-Lite 
disallows axioms about data properties", and the last line of this section 
defines axioms as "axioms := classAxiom | objectPropertyAxiom | fact". To 
be consistent with the fact that data properties are not allowed, "fact" 
needs to be redefined to exclude dataPropertyAssertion.

Section 4.3.1: OWL-R Full Weakened OWL 1.1 Full Semantic Conditions

10)       I find this section a bit difficult to read probably because I 
am not as familiar with OWL Full semantics as the authors. I had to go 
back and reread OWL Full semantics before having a better grasp on this 
section.  I think readability could be significantly improved by very 
briefly reminding the definitions of IOT, LVi , IX, EXTi, Si, IOR, IOC, 
IDC, IOOP, IODP, CEXTi. Those reminders don?t have to be formal 
definitions (e.g. IOT could be defined as "the set of OWL individuals", 
LVi as "the set of literal values", etc). 
11)      Furthermore, since the axiomatic first order semantics given in 
section 4.3.2 is much straightforward, self-contanined (at least in the 
sense that it does not require a deep familiarity with OWL Full 
semantics),  and equivalent to the weakened OWL 1.1 Full semantic given in 
section 4.3.1, I would suggest to move section 4.3.1 to an appendix.
12)      At the beginning of section 4.3, sections 4.3.1 and 4.3.2 are 
claimed to be equivalent, which seems intuitive, but do we have a formal 
proof?
13)      In section 4.3.1, I do not understand why conditions on owl:oneOf 
are dropped whereas owl:oneOf  was allowed in antecedents in OWL-R DL. 
Does it mean that we cannot write "subClassOf(ObjectOneOf(a1, a2), A) in 
OWL-R Full?

Section 4.3.2

14)      In Table 5, the rule involving domain and subProperty, seems 
incorrect. It should be:  ( T(*?p2*, rdfs:domain, ?c)  and T(?p1, 
rdfs:subPropertyOf, ?p2) )  implies T(*?p1*, rdfs:domain, ?c) 
15)     Similar, the rule involving range and subProperty, seems 
incorrect. It should be as follows: :  ( T(*?p2*, rdfs:range, ?c)  and 
T(?p1, rdfs:subPropertyOf, ?p2) )  implies T(*?p1*, rdfs:range, ?c)
16)     In Table 5, the rule involving owl:allValuesFrom and 
rdfs:subPropertyOf  (3rd rule from the end) seems incorrect. The 
implication should be T(?c2,  rdfs:subClassOf, ?c1) instead of T(?c1, 
rdfs:subClassOf, ?c2)

Section 4.4: Relationship between OWL-R DL and OWL-R Full

17)      The main result of this section seems intuitive, but do we have a 
formal proof?

Section 5: Computational Properties

18)      The second paragraph, which starts with "Note that in languages 
that are propositionally closed", is identical to the 4th paragraph.
19)      I think we should define more precisely what we mean by 
conjunctive query. Some people might consider that, for pragmatic reasons, 
all variables are distinguished, which will make query answering less 
expensive in some cases.
20)     In Table 6, I wonder if we should add references to papers 
establishing complexity results for various fragments.


Best regards,
Achille.