Proposed OWL Knowledge Base Language

Abstract

A proposed abstract syntax is given for the Web Ontology Language. This syntax is divided into a ``light'' or frame-like part and a ``full'' part.

Table of contents

1. Introduction
2. Frame Portion of Definitions
   1. Class Definitions
   2. Property Definitions
   3. Supporting Productions
3. Fact portion
4. Non-Frame Portion of Definitions
   1. Class Definitions
   2. Property Definitions
   3. Descriptions

The yellow boxes are annotations summarising the email discussion
between 19 March and 2 April. Linked names point to the relevant email
messages in the archive (FvH).

Generally favourable comments
(Borden, Heflin, McGuinness, Motta, Brickley)

Layering status:

- Do the differences warrant a separate layer? (Borden)
- What should be the status of the layering? Didactic only, or status as
  separate language, or "compliance level"? 

Layering contents:
- move full cardinalities into the Light layer (Wallace, Motta)
- allow min cardinality 1 and max cardinality 2 (or even: full
  cardinalities) in the Light layer (McGuinness)
- include a third layer below the current Light layer (McGuinness):
    - the light frame part,
    - the more comprehensive frame part  (including things like max
      cardinality or exact cardinality other than single-valued)
    - the axiom part.
- extend set of property facets in Light layer (Motta):
  include symmetric, transitive, inverseOf, uniquelyDefining, unambigous, (Reflexive?)

Concrete syntax
- need to find a way to map this to a concrete syntax,
  while preserving simplicity of the syntax below (Heflin)

(Discussion on pro's/con's of RDF/XML not included)

Relation with UML (vHarmelen)
- RDF Schema covers subclass only
- OWL Lite covers disjointness, attributes (datatype properties),
                  relations, class-scoped attributes, 
- OWL Full covers completeness, cardinalities
- not covered are defaults, part-whole, abstract classes, leaf classes

Cardinalities have different interpretation in UML (Schreiber)

Clarifications in presentation:
- explain semantics of subProprertyOf (Wallace)
- clarify lack of need for "defining before use" (Wallace)
- clarify the meaning of "required" (Brickley)
- clarify the status of anonymous individuals (Brickley)

1. Introduction

This is a definition of a proposed language for defining OWL knowledge bases, given as an abstract syntax with an informal semantics.

An OWL knowledge base is a sequence of definitions and facts. Definitions that match the first portion of the definition productions are called frame-style definitions. All IDs below are QNames, expanding to URIs plus fragment IDs. Some of the QNames are datatypes, and have built-in meaning.

Suggestion to wrap entire ontologies in Ontology(...) (Heflin):

<ontology> ::= Ontology ( <definition>*)

2. Frame Portion of Definitions

The frame portion of the definitions capture the common, understood frame idiom. Each frame-idiom definition contains a collection of more-general classes and a collection of property definitions, in the form of the slot construct. The slot construct gives the local range of a property, whether a value is optional or required, whether there can be multiple values, and a collection of required values. As well, classes can be enumerated or be made the same or disjoint. Properties can be the same or subproperties of others and can be made functional, inverse functional, or transitive.

Naming:
- rename "slots" to "properties" (Bowen)
- rename intersectionOf, unionOf, and complementOf to  AND, OR and NOT (Heflin)

2.1 Class Definitions

The following definition defines a class as precisely the conjunction of a collection of superclasses and a collection of slot definitions.

<definition> ::= DefinedClass( <classID> [,<supers>] {,<slot>} )

<definition> ::= PrimitiveClass( <classID> [,<supers>] {,<slot>} )

Primitive/Defined
- Widespread agreement that PrimitiveClass and DefinedClass are uniformative.
- suggestion to replace PrimitiveClass and DefinedClass by indicating for each
  class which attributes (if any) completely define the class (Motta).
  Example:
  Class(Man, (completelydefiningAttributeSpec supers(Person, Male)),
             (attributeSpec slot(hasAge, range=PositiveInteger)))
- suggestion to make PrimitiveClass the default by simply stating "Class",
  and have DefinedClasses by adding an additional keyword to a "Class"
  (Schreiber, personal communication)

<definition> ::= EnumeratedClass( <classID> {,<individualID>} )

<definition> ::= SameClassAs( <classID> {,<classID>} )
<definition> ::= Disjoint( <classID> {,<classID>} )

2.2 Property Definitions

Suggestion to extend frame-like notation to properties (Heflin):

<definition> ::= Property ( <propertyId> ,<facet>* )
<facet> ::= <domain> | <range> | <supersprops> | Transitive |
SingleValued | UniquelyIdentifying
<domain> ::= domain( <classId> )
<range> ::= range( <classId> | <dataTypeRange> )
<superprops> := supers( <classId>*)

The following definitions make two properties be the same, or make one property be a sub-property of another.

<definition> ::= SamePropertyAs( <propertyID1> , <propertyID2> )
<definition> ::= SubPropertyOf( <propertyID1> , <propertyID2> )

<definition> ::= Domain( <propertyID> , <classID> )
<definition> ::= Range( <propertyID> , <classID> )
<definition> ::= Range( <propertyID> , <datatypeRange> )

<definition> ::= SingleValuedProperty( <propertyID> )
<definition> ::= UniquelyIdentifyingProperty( <propertyID> )
<definition> ::= TransitiveProperty( <propertyID> )

2.3 Supporting Productions

Superclasses are specified as one or more class ID's.

<supers> ::= supers(<classID> {,<classID>})

A datatypeRange is either a datatype or a set of data values, which consist of a datatype and the lexical representation of a data value in that datatype. All the data values in a set must have the same datatype.

<datatypeRange> ::= <datatypeID>
	          | oneOf(<dataValue> {,<dataValue>} )
<dataValue> ::= <datatypeID> , <lexical-form>

Disjointness of datatypes and classes

disputed by Connolly, Connolly, Miller.
defended by Horrocks, Horrocks.

Datatypes, classes, properties, and individuals have IDs that are QNames. Datatype IDs are restricted to a known set of QNames. Class IDs are any other QName. Both property and individual IDs have no restrictions, and can be the same as datatype, class, and property names.

<datatypeID>   ::= <QName>
<classID>      ::= <QName>
<propertyID>   ::= <QName>
<individualID> ::= <QName>

Slot definitions place restrictions on properties in classes. The range part means that all values must belong to class or datatype range. The modality part is either required, meaning that there must be at least one value for the property, or optional, producing no restriction. If the modality part is not present, there is no restriction. The multiplicity part is either singlevalued, meaning that there must be at most one value for the property, or multivalued, producing no restriction. If the multiplicity part is not present, there is no restriction. Each required part means that there must be at least one value for the property that belongs to the class or datatype range. Each value part means that the individual or data value must be a value for the property.

<slot> ::=
     slot( <propertyID> [,range=<classID>] 
                        [,<modality>] [,<multiplicity>]
			{,required=<classID>}
			{,value=<individualID>} )
   | slot( <propertyID> [,range=<datatypeRange>]
			[,<modality>] [,<multiplicity>]
			{,required=<datatypeRange>}
			{,value=<dataValue>} )
<modality>     ::=     required | optional
<multiplicity> ::= singlevalued | multivalued

3. Fact Portion

Facts state information about particular individuals in the form of a class that the individual belongs to plus properties and values. Individuals can either be named with an individualID or anonymous. The syntax here is set up to mirror the normal RDF/XML syntax.

<fact> ::= Individual( [<individualID>,] <classID> {,<propertyValue>} )
<propertyValue> ::= ( <propertyID> , <fact> )
	        | ( <propertyID> , <individualID> )
		| ( <propertyID> , <dataValue> )

Individual names can also be required to mean the same individual, or to mean different individuals.

<definition> ::= SameIndividual( <individualID> {,<individualID>} )
<definition> ::= DifferentIndividuals( <individualID> {,<individualID>} )

4. Non-Frame Portion of Definitions

In non-frame definitions, there are many more constructs for providing characteristics of classes. These constructs create descriptions. As well there are relationships between descriptions, and more characteristics of properties.

4.1 Class Definitions

The following two kinds of definition generalize the frame definitions of the same name.

<definition> ::= DefinedClass( <classID> {,<description>} )
<definition> ::= PrimitiveClass( <classID> {,<description>} )

<definition> ::= SameClassAs( <description> {,<description>} )
<definition> ::= SubClassOf( <description1> , <description2> )
<definition> ::= Disjoint( <description> {,<description>} )

4.2 Property Definitions

Domains and ranges of properties are similarly generalized.

<definition> ::= Domain( <propertyID> , <description> )
<definition> ::= Range( <propertyID> , <description-or-datatype> )

4.3 Descriptions

Descriptions include class IDs and the slot constructor. Descriptions can also be boolean combinations of other descriptions, and sets of individuals. Descriptions can also be the range, required, and value pieces of the slot constructor. Finally, descriptions can required at least, at most, and exactly a particular number of values for a property.

<description> ::= <classID>
   | <slot>
   | unionOf( <description> {,<description>} )
   | intersectionOf( <description> {,<description>} )
   | complementOf( <description> )
   | oneOf( <individualID> {,<individualID>} )
   | localRange( <propertyID> , <description-or-datatype> )
   | required( <propertyID> , <description-or-datatype> )
   | value( <propertyID> , <individualID> )
   | value( <propertyID> , <dataValue> )
   | minCardinality( <propertyID> , <integer> )
		Require at least integer values for propertyID.
   | maxCardinality( <propertyID> , <integer> )
		Require at most integer values for propertyID.
   | cardinality( <propertyID> , <integer> )
		Require exactly integer values for propertyID.

Class-expressions
Proposal to label class-expressions ("anonymous classes") explicitly as classes (Bowen).
For example, replace:
DefinedClass(HappyParent, intersectionOf(minCardinality(hasSon,1),
                                         maxCardinality(hasDaughter,1)))
by 
DefinedClass(HappyParent, intersectionOf(class(minCardinality(hasSon,1)),
                                         class(maxCardinality(hasDaughter,1))))

In some places either a description or a datatype ID or a set of data values, all from the same datatype, is allowed.

<description-or-datatype> ::= <description>
   | <datatypeID>
   | oneOf(<dataValue> {,<dataValue>} )