Hi all,
This is my second attempt to post this to the list. Apologies if this ends up as a duplicate post.
As previously promised here are some proposals for how we could extend OMN to support GCIs. These proposals are the result of discussion among a smaller group off-list. Here they are for more open discussion. Please vote on which you favour, or suggest alternatives. For those on the cc list but not yet on the owled community list - please sign up and reply on-list.
PROPOSAL 1 (most favoured in current discussion): Extend misc production to include SubClassOf:
(Originally suggested by Bijan Parsia)
Changes to BNF spec:
Addition to metaproductions:
<NT>List ::= <NT> { ',' <NT> }
<NT>2List ::= <NT> ',' <NT>List
+
<NT>BinaryList ::= <NT> ',' <NT>
misc ::= 'EquivalentClasses:' annotations description2List
| 'DisjointClasses:' annotations description2List
| 'EquivalentProperties:' annotations objectProperty2List
| 'DisjointProperties:' annotations objectProperty2List
| 'EquivalentProperties:' annotations dataProperty2List
| 'DisjointProperties:' annotations dataProperty2List
| 'SameIndividual:' annotations individual2List
| 'DifferentIndividuals:' annotations individual2List
+
| 'SubClassOf:' annotations Binary2List
e.g.
(A rel some B) SubClassOf (C rel some D) [ GCI written as in Protege]
=>
SubClassOf: (A rel some B), (C rel some D)
Advantages:
1. Perhaps the simplest possible extension to OMN to => expressiveness required. In particular, avoids adding new frames.
2. All GCIs recorded in a similar way: Misc actually already supports some types GCIs - those expressing equivalence of disjointness between class expressions (actually between every member in a list of class expressions), so the proposed extension simply completes this.
Disadvantages:
1. GCIs using SubClassOf are expressed using SubClassOf in a prefix position, rather than infix. This seems to go against the spirit of OMN in preferring infix wherever possible.
2. SubClassOf is also used as a keyword in 'Class' frames. In this case it is used in an infix position. This is potential trap/pain for writers of syntax highlighters and parsers. So, perhaps we should choose a different keyword for the misc case?
PROPOSAL 2: Extend Class stanzas to allow class expressions.
(Originally suggest by Matthew Horridge)
Changes to BNF spec:
classFrame ::= 'Class:' classIRI
>
classFrame ::= 'Class:' classIRI | description
e.g.
(A rel some B) SubClassOf (C rel some D)
=>
Class: A rel some B
SubClassOf: C rel some D
Advantages:
1. Groups together SubClassOf GCIs with a common 'subject'
2. Retains infix use of SubClassOf
3. Existing spec for Class frames gives us a way to express Equivalence and Disjointness between pairs of class expressions.
Disadvantages:
Difference between Class frames about named classes and unnamed classes is implicit.
...
PROPOSAL 3 (least favoured so far):
Add new frame for GCIs. Presumably this would work for GCIS expressing disjointness and equivalence between pairs of class expressions as well as those expressing subclassing.
Changes to BNF spec:
<Not attempted this yet>
e.g.
(A rel some B) SubClassOf (C rel some D) [ GCI written as in Protege]
=>
GCI: (A rel some B) SubClassOf (C rel some D)
Advantages:
Retains infix in a way that mirrors how GCIs look in Protege and how regular (English speaking, non-logician) users likely to write them in specs/presentations.
Disadvantages:
Adds a whole new frame with all relevant spec....
Cheers,
David