Simple OML Abbreviation Styles

~ Under Construction ~

Overview

OML abbreviation styles can provide for equivalent formalizations that is more readable. But more importantly, OML abbreviation styles are closely tied to the parsing methodology. There are three abbreviation styles: generic, specific, and intermediate. The generic and specific styles are polar opposites, while the intermediate style is somewhere in the middle. The generic style (no abbreviation) provides a syntax for a single universal grammar or DTD that is independent of domain and ontology. Each specific OML ontology can be translated into a specific domain-dependent grammar or DTD. The specific style (full abbreviation) is an instance of that domain-specific ontology, and is parseable with that domain-specific grammar or DTD.

There are two OML abbreviation forms; an object-tag form and a function-attribute form. These loosely follow two of the three RDF abbreviation forms – the object-tag form is essentially the third RDF abbreviation form with the RDF Description tag (a non-type notion) corresponding to the OML Type.Object tag; the function-attribute form is essentially the first RDF abbreviation form restricted to OML functions. In general, the Simple OML framework follows the RDF framework as closely as possible without sacrificing logical integrity. The object-tag form preceded the RDF version by several years, providing the syntax for OML version 1.5.

Simple OML does not allow the notion of a preamble for an ontology (that comes in full OML). Since all abbreviation styles and forms apply to instances only, the representation for an ontology is independent of the abbreviation styles. In Simple OML the generic type names for types are as follows. A Simple OML ontology must only use these type tags.

Simple OML type	generic kind	XML use
Type.BinaryRelation	object	tag
Type.Function	object	tag
Type.Object	object	tag
Type.Relation	object	tag
subtype	binary relation	tag
name	binary relation	attribute
source.Type	binary relation	attribute
target.Type	binary relation	attribute

In addition, the subtype relation is special, and needs two other attributes, the specific and generic attributes. So in all, there are five tags and five attributes.

In Simple OML the generic type names for instances are:

Simple OML type	generic kind	XML use
Instance.BinaryRelation	object	tag
Instance.Function	object	tag
Instance.Object	object	tag
Instance.Relation	object	tag
classification	binary relation	tag
id	binary relation	attribute
source.Instance	binary relation	attribute
target.Instance	binary relation	attribute

In addition, the classification relation is special (since it links instances and types), and needs two other attributes, the instance and type attributes. So in all (just like for types), there are five tags and five attributes.

The rules for defining the domain-specific DTD are as follows.

Objects are represented as XML elements (tags).

Objects have element content. The content model consists of a repeatable choice of the binary relation elements that have the object as their first argument.
There is a required id attribute.
Multivalent relations, which are reified as objects in Simple OML, normally have an implicit empty content (repeatable choice of nothing) since their arguments are functions.

Functions are represented as XML attributes.

Functions, as XML attributes, are all implied, since Simple OML does not have cardinality constraints.

Binary relations are represented as XML elements (tags).

Binary relations have empty content.
There is a required target.Instance attribute.

The specific style is characterized by the fact that all tags are non-generic, specific tags; that is, that none come from the Simple Ontology instance type names. All functions should be abbreviated as attributes.

The generic style is characterized by the fact that all tags come from the set of Simple Ontology type names for instances. The function-attribute abbreviation is inoperative here.

Example

In order to explain OML abbreviation styles, we consider the example of the Movie instance Casablanca (1942). In the reduced representation below there is an object type for movies with metadata for year of appearance and genre. There is also a multivalent (n-ary) relation that links movies, cast members and the character that they played. Simple OML does not have a separate type for these (that comes in full OML), and so these are reified and represented as objects.

Ontology

<Type.Object name=“Movie”>

<Type.Function name=“year” target.Type=“Natno”/>

<Type.BinaryRelation name=“genre” target.Type=“Genre”/>

</Type.Object>

<Type.Object name=“Cast”>

<Type.Function name=“movie” target.Type=“Movie”/>

<Type.Function name=“member” target.Type=“Person”/>

<Type.Function name=“character” target.Type=“String”/>

</Type.Object>

Domain Specific DTD

<!ELEMENT Movie (genre)*>

<!ATTLIST Movie

id ID #REQUIRED
year NUMBER #IMPLIED>

<!ELEMENT genre EMPTY>

<!ATTLIST genre

target.Instance CDATA #REQUIRED>

<!ELEMENT Cast EMPTY>

<!ATTLIST Cast

movie CDATA #IMPLIED

member CDATA #IMPLIED

character CDATA #IMPLIED>

The Specific Style Collection

</Movie>

<Cast

movie=“Casablanca_1942”

member=“Humphrey_Bogart”

character=“Rich Blaine”/>

The Generic Style Collection

<Instance.Object id=“Casablanca_1942”>

</Instance.Object>

<Instance.Function

source.Instance=“Casablanca_1942”

target.Instance=“1942”>

</Instance.Function>

<Instance.BinaryRelation

source.Instance=“Casablanca_1942”

target.Instance=“Drama”>

</Instance.BinaryRelation>

<Instance.BinaryRelation

source.Instance=“Casablanca_1942”

target.Instance=“Romance”>

</Instance.BinaryRelation>

<Instance.Object id=“cast1”>

</Instance.Object>

<Instance.Function

source.Instance=“cast1”

target.Instance=“Casablanca_1942”>

</Instance.Function>

<Instance.Function

source.Instance=“cast1”

target.Instance=“Humphrey_Bogart”>

</Instance.Function>

<Instance.Function

source.Instance=“cast1”

target.Instance=“Rich Blaine”>

</Instance.Function>

An Intermediate Style Collection

</Movie>

<Cast>

<character>Rich Blaine</character>

</Cast>

Please send questions, comments and suggestions about this page to: Robert E. Kent rekent@ontologos.org