W3C home > Mailing lists > Public > public-owl-wg@w3.org > April 2009

Re: Review of QRG (Action 307)

From: Jie Bao <baojie@cs.rpi.edu>
Date: Wed, 8 Apr 2009 12:23:59 -0400
Message-ID: <b6b357670904080923x62ec8d8ex72e1aa1efb225f8b@mail.gmail.com>
To: Christine Golbreich <cgolbrei@gmail.com>
Cc: "Deborah L. McGuinness" <dlm@cs.rpi.edu>, Elisa Kendall <ekendall@sandsoft.com>, Evan Wallace <ewallace@cme.nist.gov>, W3C OWL Working Group <public-owl-wg@w3.org>
Christine

Thanks for the review. Some of them are incorporated into the new
version. More details are line.

Jie

2009/3/25 Christine Golbreich <cgolbrei@gmail.com>:
> Status (2nd paragraph)
> --------------
> - it would be better tro have Syntax first and Primer next, since it's
> a guide to the different documents and Syntax has normative content.
> - suggested sentence like:
> -> The Quick Reference Guide provides links into other documents that
> it is intended to complement, particularly šthe Syntax document for
> more details of syntax, the OWL 2 Primer for examples, and the New
> Features and Rationale document for the new features of OWL 2 .
>
While doing that could be reasonable, in layout it cause confusion. In
tables, we always first give the feature's name with link to Primer,
and then the functional syntax with link to Syntax. It will be more
difficult to read if we switch their order. Thus, I'm intent not to
make change.

> Structure of the document
> ---------------------------------
> I'm not convinced by the proposed strutcuration. Since QRG is a guide
> to other documents (IMO) it would be prefered to follow the structure
> of OWL 2 SS - that is to separate entities (class/properties) and
> axioms (class/properties) in different sections.
> However, šif šyou want to keep this organization with class
> expressions and axioms together, I suggest to slightly reorganize and
> e to rename the subsections for example like:
>
> 2.1 Classes
> 2.1.1 Class Expressions
> - Boolean Connectives and Enumeration of Individuals
> - Object Property Restriction
> - Object Property Cardinality Restrictions
> - Data Property Restrictions
> - Data Property Cardinality Restrictions
> 2.1.2 Class Axioms
> Subclass, Equivalent, Disjoint , Disjoint Union of Classes Axioms
>
> 2. 2 Properties
> 2.2.1 Property Expressions
> - Object Property Expressions
> - Data Property Expressions
> 2.2.2 Property Axioms
> - Object Property Axioms
> *Subproperties, Equivalent, Disjoint, Inverse Properties
> *Domain, Range
> *Properties characteristics
> (Functional, Inverse-Functional Reflexive, Irreflexive , Symmetric ,
> Asymmetric , Transitive Properties)
> - Data Property Axioms
> *Subproperties, Equivalent, Disjoint
> *Domain, Range
> *Functional Properties
> - Datatype Definitions
> - Keys
> 2.2.3 Data Ranges
> - Intersection, Union, Complement of Data Ranges
> - Enumeration of Literals
> - Datatype Restrictions
>
> 2. 3 Declaration
>
> 2.4 Assertions
>
> 2.5 Annotations
>
> etc.
>
Restructured as you suggested

> Titles
> -----------
> - all duplicated titles should be removed
>
> - 2 OWL/OWL 2 Vocabulary
> The title 2 OWL/OWL 2 Vocabulary does not brings much. I'd remove this
> level and start directly with 2.1 Classes
> If you really want to keep it, change the title to š"OWL 2 vocabulary"
> or "OWL 2 constructs and axioms"
>
Changed to "OWL 2 constructs and axioms"

> Notations and display
> --------------------------------
> - I'd suggest to follow the notations used in the Syntax e.g. OPE, DPE
> for object property expression, etc. This would make easier a smooth
> transition to the SS document and would also be more consistent with
> NF&R notations which has adopted the same conventions as the syntax
> doc:
>
> "CE" is a Class Expression, "DR" is a data range, "OPE1" and "OPE2"
> are object property expressions, "DPE1" and "DPE2" are data property
> expressions, "a" is an OWL individual, "lt1" and "lt2" are literals,
> "n" is a non-negative integer. All names may have subscripts.
> "(lt1 ... ltn)" stands for a *set*.
> etc.
>
While it is a good idea, I'm concerned with space, as finally we have
a very squeezed layout to fit in two pages (hopefully). Each letter
saved may make it easier. I added an EdNote on that, and will come
back if space turns out not an issue.

> - šremove all 4th columns which are no more necessay with conventions
>
I removed as much as I can.

> - (to be consistent with other docs) for bnode better to use _:x than x
>
Fixed

> New features
> -------------------------
> having the whole line in a lighter grey or in another color is OK, but
> a different font would not be enough clear
> you may replace braces by a circle or square -> have a question mark
> within a circle/square for links to NF&R
>
I tried coloring, does not work very well with hyperlinked items. Thus
I now use bold font for new features

> 2.1.1 everywhere change [ .. š ] by ( )
> intersectionOf [ C1 ... Cn ]. -> intersectionOf (C1 ... Cn )
> Moreover [ C1 ... Cn ] is not a *list* but a *set* of concepts
>
Fixed

> 2.1.2
> - Remove : Every owl:Restriction is an owl:Class.
>
I would see this information is useful, and it justifies why
restrictions are listed in the class section. Thus, I incline to keep
it.

> - I would change the order and put qualified card restrictions first
> - have only 2 lines for each:
>
> if C is missing
> x owl:cardinality n.
> if C presents
> x owl:qualifiedCardinality n.
> x owl:onClass C.
>
> ->
>
> x owl:qualifiedCardinality n.
> x owl:onClass C š š š š š š š (with C)
>
> x owl:cardinality n.
> if C presents š š š š š š š š š (without C)
>
Compact representation is always welcome

> 2.1.3
> - same as 2.1.2
> - šIn Restrictions Using n-ary Data Properties
> there are 2 different notions to give (IMO): "n-ary
> universal/existential" and n-ary data range "Dn"
> - appelation 'n-ary' universal/existential should be changed ->
> existential, and quantified restrictions on mutiple data properties.
> cf. DataSomeValuesFrom( DPE1 ... DPEn DR ) consists of n data property
> expressions DPEi, 1 ˜ i ˜ n, and a data range DR whose arity MUST be n
>
I changed all "n-ary data property" to "n-ary data range".

> 2.2
> - typo: remove šcan be con be
>
Fixed
> š-> All datatypes (rdfs:Datatype) are unary data ranges. Complex data
> ranges are constructed from data types and other data ranges.
>
>
> 2.3.1 -2.3.2- 2.3.4
> - remove column 4
>
Done

> 2.4
> - Update HasKey syntax:
> HasKey( { A } CE ( OPE1 ... 0PEm ) ( DPE1 ... DPEm ) )
>
Done

> - NF&R šlink is broken
> http://www.w3.org/2007/OWL/wiki/New_Features_and_Rationale#F9:_Key
> ->
> http://www.w3.org/2007/OWL/wiki/New_Features_and_Rationale#F9:_Keys
>
Fixed

> 2.5
> - it would be more friendly if you use "a" rather than š"i" for
> indiviuduals (see proposed notations ) š:
>
> ij owl:sameAs ij+1.-> aj owl: sameAs šaj+1
>
Done

> 2.6
> - not sure this section is needed, I'd remove it
> - see also previous comment on [.. ] convention
>
Removed

> 2.9
> - suggest to distinguish (like in NF&R) :
> Annotation of IRI or anonymous individual
> Annotation of axiom
> Axioms on annotation properties
>
Updated

> 3
> - Remove Global Restrictions on Axioms in OWL 2 DL
>
Removed

>
> 4.
> - Facets should be at the same place than Datatype restriction
> - and a single section, entitled for example like 'Extended
> datatypes', šmight gather both unary and n-ary datatypes
>
> - Unary Datatype
> *Built-in Datatypes
> *Datatype Restriction and Facets.
>
The intuition to have datatypes and facets grouped together is that to
give facets , we have to first give available datatypes in OWL2.
Datatype restriction creates new data ranges, thus I believe its best
to be grouped with other data range connectives.

> - N-ary datatype (non in OWL 2)
>
> --
> Christine
>



-- 
Jie Bao
http://www.cs.rpi.edu/~baojie
Facebook,Twitter,Skype,Msn,LinkedIn - check url above
Received on Wednesday, 8 April 2009 16:24:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 8 April 2009 16:24:41 GMT