P4AnonymousClasses - Revision history

TaniaTudorache at 04:13, May 24, 2016

2016-05-24T04:13:02Z

Nickdrummond at 16:26, January 8, 2009

2009-01-08T16:26:15Z

Nickdrummond: /* Notes on implementation */ updated rewriting

2009-01-08T15:00:28Z

‎Notes on implementation: updated rewriting

Nickdrummond: /* Anonymous Defined Classes (ADCs) */

2008-12-10T11:02:42Z

‎Anonymous Defined Classes (ADCs)

Nickdrummond: updated with implementation notes

2008-12-10T11:01:42Z

updated with implementation notes

Nickdrummond: Note on class hierarchy usage

2008-12-09T17:48:34Z

Note on class hierarchy usage

Nickdrummond: /* Viewing ADCs */

2008-12-09T11:54:24Z

‎Viewing ADCs

Nickdrummond: /* Viewing ADCs */

2008-12-09T11:53:56Z

‎Viewing ADCs

Nickdrummond: /* inline vs reference */

2008-12-02T16:24:39Z

‎inline vs reference

Nickdrummond: /* inline vs reference */

2008-12-02T16:14:41Z

‎inline vs reference

@@ Line 1: / Line 1: @@
 <div class="orangeBox">
 <span class="orangeBoxTitle">Protege 4.x Anonymous Classes</span><br /><br />
 This page describes features that are under development and not currently available in a P4 release.
 </div><br />

@@ Line 1: / Line 1: @@
 <div class="orangeBox">
 <span class="orangeBoxTitle">Protege 4.x Anonymous Classes</span><br /><br />
-This page describes features that will be available from build105 onwards.
+This page describes features that are under development and not currently available in a P4 release.
 </div><br />

@@ Line 161: / Line 161: @@
 * should not be renamed
 * should not be referenced directly - every time one is used in an axiom, it should be replaced by its expression
 This puts the onus on developers of p4 plugins to handle ADCs wherever OWLClasses are used. We can only help with this to a certain extent by returning descriptions from class tree selectors and wrapping reasoner results etc (all things that break the current APIs), but the developer can always get to them through OWLOntologyManager calls (eg getReferencedClasses())
@@ Line 173: / Line 186: @@
 Now create a subclass of $1
-'''by reference''':
+==== by reference ====
    B -> $1
 * $1 is treated as a normal named class
@@ Line 195: / Line 208: @@
-'''inlined''':
+==== inlining ====
    B -> p some A
 * $1 is treated like a rubber stamp for creating expressions
@@ Line 208: / Line 221: @@
 It is safer wrt changing the definition (difficult to make this immutable) - ie it does not have side effects on all the things referencing it.

@@ Line 34: / Line 34: @@
 '''causes some HeartMurmur'''
-See [[P4AnonymousClasses#Note_on_implementation|notes on this implementation]]
 <br style="clear: both;" />

@@ Line 33: / Line 33: @@
 '''causes some HeartMurmur'''
 <br style="clear: both;" />
@@ Line 143: / Line 145: @@
 The definition of an ADC is now immutable wrt to the Class Description view, but other editors/actions can still change it (eg '''Convert to primitive class''')*.
 === inline vs reference ===
-Its not clear whether the ADC itself should ever be referenced in other axioms, or whether the expression should always be used in its place at the time of creation:
+Arguably, the ADC itself should never be referenced by other axioms, the expression should always be used inline at the time of creation. If ''by reference'' is required it is felt that the user would be happy to create a named class.
 eg $1 is an ADC defined as below
@@ Line 153: / Line 172: @@
 Now create a subclass of $1
-Option 1: this could be done '''by reference''':
+'''by reference''':
    B -> $1
 * $1 is treated as a normal named class
@@ Line 160: / Line 179: @@
 * B shows up as a subclass of $1 in the class hierarchy without any extra coding
 * $1 shows as referenced by B in the usage view without any extra coding
 All trees/selectors etc just pass back named classes as they always did.
-However, it becomes important to be able to distinguish between the ADC and an equivalent expression (as they behave differently).
+By reference does not require any special handling by P4. ADCs effectively become just a presentational issue.
 eg in the class description view for B we might have the following where one is an ADC and one is a class expression:
@@ Line 173: / Line 191: @@
 * p some A
-This means altering the rendering for ADCs.
+This would mean altering the rendering for ADCs with some additional notation - speech marks or whatever.
-Option 2: this could be '''inlined''' to create:
+'''inlined''':
    B -> p some A
 * $1 is treated like a rubber stamp for creating expressions
@@ Line 191: / Line 209: @@
 Inlining has been implemented for the Class Description view - equiv, super, class assertions and disjoints are inlined - which gives us a nicer interface for GCAs (see above).
 However, it may be tricky to enforce inlining for other views/actions (especially developed by third parties) - and it is not intuitive to look for these special cases - we would have to publish developer notes.
 Another possibility is to filter the ontology changes as they are applied and always replace the ADC with its expression (but then the real changes don't reflect what the user asked for).

@@ Line 6: / Line 6: @@
 Back to [[Protege4UserDocs]]
-<br /><br />
 == Anonymous classes in OWL ==
@@ Line 73: / Line 75: @@
 * They '''should''' be immutable in the interface - eg the equivalent class is not visible/editable in the class description view
@@ Line 102: / Line 102: @@
 <br style="clear: both;" />
-== ADCs and General Class Axioms (work in progress) ==
 [[Image:Anon-classes-GCAs.png|right|400px]]

← Older revision		Revision as of 11:54, December 9, 2008
Line 74:		Line 74:
	* They '''should''' be immutable in the interface - eg the equivalent class is not visible/editable in the class description view		* They '''should''' be immutable in the interface - eg the equivalent class is not visible/editable in the class description view

−	* ~~Editing~~ them '''should''' ~~act~~ as if using the expression itself - it should be inlined [[P4AnonymousClasses#inline_vs_reference\|arguably]]	+	* Using them '''should''' behave as if using the expression itself - it should be inlined [[P4AnonymousClasses#inline_vs_reference\|arguably]]

@@ Line 70: / Line 70: @@
 * They are not indexed for searches
-* They cannot be used in the class expression editor
+* They cannot be used in the class expression editor (although they could be used as a source for [[Protege4ExpressionEditor#Expression_completion|expression completion]])
-* Editing them '''should''' act as if using the expression itself (ie it should be inlined - work in progress)
+* They '''should''' be immutable in the interface - eg the equivalent class is not visible/editable in the class description view

@@ Line 145: / Line 145: @@
 * changing the definition of $1 in the future changes the definition of B
 * deleting $1 removes the above axiom (note that deleting A does not remove the above axiom but obviously changes the meaning of B)
-* B just shows up as a subclass of $1 in the class hierarchy
+* B shows up as a subclass of $1 in the class hierarchy without any extra coding
 By reference does not require any special handling by P4. ADCs effectively become just a presentational issue.
@@ Line 151: / Line 152: @@
 All trees/selectors etc just pass back named classes as they always did.
-However, there are several nice properties missed that inlining gives us.
+However, it becomes important to be able to distinguish between the ADC and an equivalent expression (as they behave differently).
@@ Line 159: / Line 168: @@
 * we lose the link between the expression and $1 (we can of course index these though)
 * deleting $1 does not affect the above axiom (however, note that deleting A removes the above axiom)
-* Asub does not show up under $1 without special treatment of ADCs in the hierarchy providers
+* B does not show up under $1 without special treatment of ADCs in the hierarchy providers
 This is closer to the intuition of seeing the expression in the interface - users will not care about the class behind the expression.