- From: Ignazio Palmisano <ipalmisano.mailings@gmail.com>
- Date: Tue, 25 Aug 2015 13:58:40 +0300
- To: Simon Spero <sesuncedu@gmail.com>, public-owl-comments@w3.org, Owl Dev <public-owl-dev@w3.org>
- Cc: "owlapi-developer@lists.sourceforge.net" <owlapi-developer@lists.sourceforge.net>
On 25 August 2015 at 04:12, Simon Spero <sesuncedu@gmail.com> wrote: > The investigation of some errors reported in the OWLAPI profile checkers > (see owlapi issue #435) has revealed what appear to be some errors and > ambiguities in the OWL 2 Profile Specification document. > > 1. Defined Datatypes > > All three profiles use the phrase <profile> "supports the following > datatypes" > > EL: §2.2.1 > QL: §3.2.1 > RL: §4.2.1 > > The OWLAPI profile checkers have been interpreting this as exhaustive > enumeration. This is consonant with the corresponding text on data ranges. > >> 2.2.4 Data Ranges >> >> "A data range expression is restricted in OWL 2 EL to the predefined >> datatypes admitted in OWL 2 EL, intersections of data ranges, and to >> enumerations of literals consisting of a single literal." > > >> 3.2.4 Data Ranges >> A data range expression is restricted in OWL 2 QL to the predefined >> datatypes and the intersection of data ranges. > > >> 4.2.4 Data Ranges >> >> A data range expression is restricted in OWL 2 RL to the predefined >> datatypes admitted in OWL 2 RL and the intersection of data ranges. > > > However, all three profiles include the DatatypeDefinition axiom. Either > this axiom can define Data Ranges which can never be referred to, or, if > DataType is restricted to the pre-defined types, can only be used to > illegally attempt to redefine one of those pre-defined types (such > redefinition is not explicitly prohibited in the Structural Fun Syntax Spec; > it's just not possible). > > It would seem that the clear intent behind allowing datatype definition > axioms in the profiles would have been to permit the use of those > definitions as data ranges where such use would be permitted in OWL 2 DL, > and that sections [2-4].2.4 are in error. > > 2. Irreflexive Property Axioms in OWL QL > > In the overview of OWL QL features in §3.1, OWL 2 QL is stated to support > "reflexive properties (ReflexiveObjectProperty)" and "irreflexive > properties (IrreflexiveObjectProperty)". > > However in the detailed specifications of axioms in § 3.2.5 , > IrreflexiveObjectProperty is omitted from the production for > ObjectPropertyAxiom. > This omission is repeated in the full OWL 2 QL grammar in §6.2. There is > also no production for IrreflexiveObjectProperty. > > It is not immediately obvious why IrreflexiveObjectProperty would be > problematic for QL (there is no transitivity or chains, and reflexivity is > supported). Is the omission from the grammar accidental? > That's what I have assumed in the fix described below. > I am trying to figure out when this divergence happened; reflexivity is not > mentioned at all in the OWL 1.1 Tractable Fragments submission, and the > divergence is already present in the first version of the Profile document > to appear on the Wiki. > > 3. OWLAPI bugs > > DisjointClasses axioms were incorrectly flagged as violations of QL and RL. > (This error had been spotted and fixed for EL in February 2015). > > I believe that these errors were introduced at the end of March 2014. > Yep. My bad. > Note: I believe that profile checkers are now over-generating (the elements > in the class are not being checked to see if they are valid subclass > expressions). This will be fixed shortly. > Now fixed in version4 branch (soon to be 4.1.0) > DisjointDataProperties, EquivalentDataProperties and DataIntersectionOf > were incorrectly flagged as violations of RL. > > ReflexiveObjectProperty was incorrectly not flagged as a violation of RL. > > Ignazio Palmisano resolved the ambiguity in (2) in favor of not flagging > irreflexive properties as violations of QL by Executive Fiat . > Indeed. To support my decision, I am on the executive board for one such car, which makes me a Fiat Executive x 10^-7 (rounded up) > No action has been taken on issue 1. > > > 4. OWLAPI Tools bugs > > (Not Addressed) > > The issues with DisjointClasses are not present in the OWLAPITOOLS version > of the profile checkers (These errors were introduced when the code was > integrated into OWLAPI). > > The other issues list above were (and remain) present in the owlapitools > code. > > Simon > Once the dust settles on issue 1 I'll amend OWLAPITOOLS to do the same as OWLAPI does. Cheers, Ignazio
Received on Tuesday, 25 August 2015 10:59:11 UTC