Difference between revisions of "P4AnonymousClasses"

From Protege Wiki
Jump to: navigation, search
(Viewing ADCs)
(Viewing ADCs)
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]]  
  
  

Revision as of 04:54, December 9, 2008

Protege 4.x Anonymous Classes

This page describes features that will be available from build105 onwards.


Back to Protege4UserDocs



Anonymous classes in OWL

Anonymous classes (ACs) are used throughout OWL ontologies. Any class expression, including restrictions, intersections, unions, enumerations etc is an anonymous class.

In general, these are seen as subsidiary within OWL editors, such that the class hierarchy and all navigation is focused on named things.

In many cases we are interested in exploring arbitrary expressions, perhaps for testing purposes, or just to make the ontology more clear. This is the reason the DL query tab is so useful - we can use it to test definitions and ensure the quality of our ontological definitions. The problem with the DL query tab up to now has been that the expressions entered were not saved - so the user was forced to cut and paste handy ones into a text editor or an annotation.


Anonymous Defined Classes (ADCs)

P4 now allows ACs to be added to the ontology in such a way that they can be saved and browsed just like ordinary classes.


ADCs are exactly like normal defined classes - ie they are a class that have an asserted equivalent class:

eg defined class ThingsThatCauseSomeHeartMurmur equivalentTo causes some HeartMurmur


BUT we don't have to provide a rediculous/meaningless name for them. They are automatically given a URI internally and are visible in the interface as an expression:

causes some HeartMurmur


Creating ADCs

Creating a class by right clicking on an expression
Creating a class from the DL Query Tab

There are currently two places you can create an ADC:

  1. Right click on expressions
    1. select a class expression in the Class, Property or Individual Description views
    2. right click and select Create new defined class
  2. DL query view
    1. type an expression into the DL query editor
    2. select Add to ontology


You will be presented with the following dialog:

Create equivalent class dialog

If you leave the option as Anonymous class you will create an ADC.

If you choose to name your class, you will end up with a normal defined class (that is equivalent to the expression you had selected).


Viewing ADCs

Anon class in asserted tree.png
Anon class in inferred tree.png
Anon class description.png

ADCs are treated differently from named classes in the following ways:

  • Rendering preferences are ignored. They are always rendered with the content of their equivalent class
  • They are not indexed for searches
  • They cannot be used in the class expression editor (although they could be used as a source for expression completion)
  • They should be immutable in the interface - eg the equivalent class is not visible/editable in the class description view
  • Using them should behave as if using the expression itself - it should be inlined arguably


In all other respects they act just as named classes:

  • ADCs will be placed in the asserted and inferred class hierarchy
  • Selecting an ADC will cause the global selection to change
  • The Class description view will show asserted and inferred information about the ADC (but not its actual definition)
  • They will show up in inferred sections of all entity description views where appropriate


Anonymous defined classes view

In addition, there is a view under Views | Class views | Anonymous defined classes that shows just the ADCs in a flat list.

This list affects global selection.

You can also delete the ADC from the ontology by clicking the Remove button.

The list should implement cut and paste.

Anon classes view.png


ADCs and General Class Axioms (work in progress)

Anon-classes-GCAs.png

General class axioms (GCAs) are any subClass, equivalentClass or disjointClass statement that has an AC on the left hand side.

eg "any person that owns a TV cannot avoid watching a reality show"

 Person and owns some Television subClassOf watches some RealityShow

GCAs are generally created in the General class axioms view.

GCAs will show up in the Class Description view for any ADCs that it contains (lhs for subClassOf).

Any sub/equiv/disjoint assertions made in a ADC's Class Description view will be added as a GCA.

GCAs can also be deleted directly in the Class Description view.


Warnings

P4 has not been restrictive about your use of ADCs. As this is a new feature we will need some feedback of users experience with this mechanism.

ADCs are currently not part of the OWL2.0 specification and are internally represented and serialised as normal named classes. Therefore, other tools/APIs will not treat them as special.

We currently use naming conventions to mark ADCs - the prefix http://www.co-ode.org/ontologies/owlx/anon# is reserved for this purpose. Please do not rename ADCs.

Although unlikely because of the way IDs are generated, we cannot guarantee uniqueness when working with several ontologies that all use ADCs (in the same way we should be able to with anonymous individuals). Equally, we cannot close the scope of the ADCs to a single ontology (again, as we can with anonymous individuals).

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:

eg $1 is an ADC defined as below

 $1 = p some A

Now create a subclass of $1

Option 1: this could be done by reference:

 B -> $1
  • $1 is treated as a normal named class
  • 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 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

By reference does not require any special handling by P4. ADCs effectively become just a presentational issue.

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).

eg in the class description view for B we might have the following where one is an ADC and one is a class expression:

superclasses

  • p some A
  • p some A

This means altering the rendering for ADCs.


Option 2: this could be inlined to create:

 B -> p some A
  • $1 is treated like a rubber stamp for creating expressions
  • 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)
  • B does not show up under $1 without special treatment of ADCs in the hierarchy providers
  • B does not show up in the usage of $1 without special treatment of ADCs in the usage indexing

This is closer to the intuition of seeing the expression in the interface - users will not care about the class behind the expression.

We don't have to distinguish between the ADC and the expression (so behaviour is the same regardless of where you see the rendering).

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.

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).