12.5 Basic Constructs of OWL


In this section, we'll look at the basic elements of OWL, those that exist regardless of the ontology being defined. If you're familiar with RDFS (as covered in Chapter 5), most of these should be familiar to you. Specifically, in this section we'll cover the following OWL elements:

  • owl:Class

  • owl:Datatype

  • owl:DatatypeProperty

  • rdfs:domain

  • owl:imports

  • owl:ObjectProperty

  • owl:Ontology

  • rdf:Property

  • rdfs:range

  • rdfs:subClassOf

  • rdfs:subPropertyOf

  • owl:versionInfo

RDF Schema and OWL are compatible, which is why you'll see RDFS elements within the OWL element set. However, the direction of this compatibility is one way ” only from RDF and RDF to OWL; you won't see OWL elements within the RDF Schema.

You start an OWL ontology with the header, covered next .

12.5.1 OWL Header

The first component is the outer OWL block, delimited by owl:Ontology , containing version information (through owl:versionInfo ) and an imports section (through owl:imports ). The imports section includes an rdf:resource attribute that points to a separate RDF resource providing definitions used with the ontology. This could include the complete schema for the ontology.

Redefining PostCon as an OWL ontology rather than a vocabulary defined directly in RDFS, the OWL header would be similar to the following:

 <rdf:RDF      xmlns:pstcn="http://burningbird.net/postcon"      xmlns:owl ="http://www.w3.org/2002/07/owl#"     xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"     xmlns:dc="http://purl.org/dc/elements/1.1/"     xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"> <owl:Ontology rdf:about="http://burningbird.net/postcon">   <owl:comment>PostContent Management</owl:comment>   <owl:versionInfo>         $Id: ch12.xml,v 1.5 2003/07/17 20:16:25 chodacki Exp $   </owl:versionInfo>   <dc:creator>Shelley Powers</dc:creator>   <dc:title>PostCon</dc:title> </owl:Ontology> </rdf:RDF> 

The namespaces are familiar as is the use of the outer rdf:RDF opening and closing tags. However, note that I used a different namespace for PostCon. I'm not defining a schema for the existing RDF vocabulary ”I'm creating a new ontology, from the ground up, using RDF/XML and based on the business domain behind the vocabulary.

New material introduced in the header is the outer Ontology block to contain the ontological definitions and the version information elements, as well as the ontology comments. This section could also have included an import statement, to import another ontology, but none is defined for PostCon at this moment. Importing differs from inclusion of a namespace by incorporating that ontology's assertions into the ontology currently being defined, therefore making them part of the knowledge base on which the new ontology is being built.

The version information shown is one difference between RDF and OWL ”OWL assumes that different versions of the ontology will be developed, therefore it's imperative to maintain this type of information with the document for each version.

Dublin Core elements are included in the header to provide title, creator, and other information, since this ontology is a published resource, and DC was designed to document metadata about published resources. It's not required ”really, little of this material is required ”but any extra information helps.

Between the OWL header and the final RDF closing tag is the definition of the classes and properties of the ontology itself.

12.5.2 OWL Classes and Individuals

Not unlike RDFS, OWL classes define entities via properties. The classes defined for the PostCon ontology should therefore be similar to those defined with RDFS in Chapter 6. What might be more apparent with OWL is the hierarchical nature of the classes.

In PostCon, there is a Resource , which is basically anything being tracked with the PostCon system. During the tracking process, the Resource moves from location to location, each of which is tracked as a movement. It still has all the characteristics of being a Resource ; the movement doesn't change this. However, there are new characteristics associated with the item. The ResourceMovement , then, becomes a subclass of Resource . In addition, there are other resources that are related in some way to the Resource . RelatedResource is also defined as a subclass of Resource :

 <owl:Class rdf:ID="Resource" /> <owl:Class rdf:ID="RelatedResource">    <owl:subClassOf rdf:resource="#Resource" /> </owl:Class> <owl:Class rdf:ID="ResourceMovement">    <owl:subClassOf rdf:resource="#Resource" /> </owl:Class> 

There are other possible classes within PostCon ” for instance, different types of resources, such as photos, text documents, music, and video ”each of which has different properties unique to the type of the object.

However, within the PostCon system, much of the uniqueness of each individual object can be described using the same properties. For instance, a requirement for viewing a video file is a browser plug-in that enables this, a requirement for a music file is the same, and so on. Each type of object has a requirement, and one property can capture this requirement for all the types. In this case, rather than each object type being a separate class, they're all instances of the same class. In ontological terms, each of these types of resource is an individual member of the class, rather than a subclass of it.

12.5.3 OWL Simple Properties and Complex Data Types

An OWL property is really not that much different from a property defined in RDFS. They share the same use of rdfs:domain and rdfs:range , but in addition, constraints that aren't defined in RDFS can be applied to OWL properties.

In PostCon, one property of a resource movement is its movement type information. The definition for it in OWL is very similar to what we would find in the RDF Schema:

 <owl:ObjectProperty rdf:ID="movementType">    <rdfs:domain rdf:resource="#ResourceMovement">    <rdfs:range rdf:resource="" /> </owl:ObjectProperty> 

The property movementType has a domain of ResourceMovement , which means that any resource with this property is a ResourceMovement . If a property inherits all the characteristics of another, it's a subproperty of the original, noted in OWL with the subPropertyOf property.

However, where RDFS and OWL differ, quite dramatically, is in data typing. Both specifications use XML Schema data types; both allow the use of data type within the schema definition (within the class definition for OWL, RDFS for RDF); and both allow annotation of instances with data type (individual for OWL, in actual properties in RDF). The two differ in that RDF limits data types to those types that can be referenced by URI, such as the predefined schema instances (in http://www.w3.org/TR/xmlschema-2/). OWL extends the concept of data type to include creating classes of data types that are then used to constrain the range of properties.

To demonstrate , consider the movementType property just defined using ObjectProperty . The domain is ResourceMovement , and we could say it has a range of rdf:Property , which would be correct; however, it would also be too diffuse, because movementType has one other constraint attached to it: there are only three allowable values, "Add" , "Drop" , and "Move" . Within RDFS there is nothing to automatically constrain the data used with movementType other than to use xsd:string to state it's a string and rdf:Property to state it's a property.

In OWL, though, we can do much more. Borrowing from the design of the data types for the example Wine ontology in the OWL Guide, I created a custom XML Schema data type definition file as follows :

 <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"         xmlns="http://burningbird.net/postcon/postcon-pstcn.xsd"> <xsd:simpleType name="movementTypes">   <xsd:restriction base="xsd:string">     <xsd:enumeration value="Add"/>     <xsd:enumeration value="Drop"/>     <xsd:enumeration value="Move"/>   </xsd:restriction> </xsd:simpleType>  </xsd:schema> 

This new simple type has a base restriction of string , but it also lists an enumeration of allowable values ” "Add" , "Drop" , and "Move" . To tie this into my ontology, I would then create a data typing class to represent this movement type:

 <owl:Class rdf:ID="MovementType" /> 

I can then tie the data type restrictions to the MovementType class, using DataTypeProperty :

 <owl:DataTypeProperty rdf:ID="movementTypeValue">   <rdfs:domain rdf:resource="#MovementType" />       <rdfs:range rdf:resource="pstcn:movementType"/> </owl:DataTypeProperty> 

Finally, I can complete the property definition for movementType , by adding an rdf:range that uses the new data type class:

 <owl:ObjectProperty rdf:ID="movementType">    <rdfs:domain rdf:resource="#ResourceMovement" />    <rdf:range rdf:resource="#MovementType" /> </owl:ObjectProperty> 

This seems a bit complex, but one restriction on allowable values for rdf:range is that they must be class values, such as rdf:Property . Using this approach, the RDF Schema requirements are met, but the greater needs of the ontology ”being allowed to specify an enumeration of allowed items ”are also met.



Practical RDF
Practical RDF
ISBN: 0596002637
EAN: 2147483647
Year: 2003
Pages: 131

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net