Difference between revisions of "P4AnonymousClasses"

From Protege Wiki
Jump to: navigation, search
Line 1: Line 1:
<div class="orangeBox">
<div class="orangeBox">
<span class="orangeBoxTitle">Protege 4.x Anonymous Classes</span><br /><br />
<span class="orangeBoxTitle">Protege 4.x Anonymous Classes</span><br /><br />
<b>This page is outdated.</b> <br />
This page describes features that are under development and not currently available in a P4 release.
This page describes features that are under development and not currently available in a P4 release.
</div><br />
</div><br />

Latest revision as of 21:13, May 23, 2016

Protege 4.x Anonymous Classes

This page is outdated.
This page describes features that are under development and not currently available in a P4 release.

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

See notes on this implementation

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

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

Using ADCs

Using ADCs should behave as if using the expression itself - it should be inlined arguably.

In the class hierarchy:

  • Add subclass will create a new class and cause the expression represented by the ADC to be added as a superclass. Note that it will not be placed under the ADC in the asserted hierarchy, but should in the inferred hierarchy once the reasoner has classified
  • Add sibling will behave exactly as it should
  • Delete selected class will remove the ADC, but will not remove use of the expression elsewhere in the ontology

ADCs and General Class Axioms


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.


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

Notes on implementation

The choice of implementing ADCs as named defined classes has several advantages:

  1. it allows them to fit into all existing views with a change only to the way the class is rendered
  2. it allows them to be serialized/loaded without any extension to the writers/parsers
  3. it allows them to be returned from reasoner queries

Disadvantages stem from the fact that they must be treated as a 'special case' outside of OWL.

If we wish to inline (see below) only then ADCs:

  • should not be renamed
  • should not be referenced directly - every time one is used in an axiom, it should be replaced by its expression

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.

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

Change rewriting

One alternative for supporting inlining is to filter the ontology changes as they are applied and always replace the ADC with its expression.

  • most code does not need to know anything about ADCs to work correctly
  • but then the real changes don't reflect what the user asked for
  • not all axioms can take an OWLDescription in place of a named class (eg entity annotations)

inline vs reference

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

 $1 = p some A

Now create a subclass of $1

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

All trees/selectors etc just pass back named classes as they always did.

By reference does not require any special handling by P4. ADCs effectively become just a presentational issue. It would be 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:


  • p some A
  • p some A

This would mean altering the rendering for ADCs with some additional notation - speech marks or whatever.


 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.