|
Kiril Simov
|
(c) OntoText Lab.
One purpose of this document is to provide a single consistent all-in-one source for understanding of the DAML+OIL syntax - due to more or less respectable reasons such was not available at moment of publishing. Another purpose is to explicate some inconsistencies among the sources. See, for instance, the end of section 4. A more pragmatic goal, was to define a way to manage DAML+OIL ontologies and instance data stored in RDF(S) repository, such as SESAME.
Relevant parts of the documents that define the syntax of DAML+OIL and RDF(S), as its base, are compiled in the first four sections. Analysis of the different syntactic patterns for the purpose of classification of the resources involved is presented in section 5. On top of this, section 6 presents algorithm for classification of the RDF statements used to represent DAML+OIL.
Most of the volume of the document consists of texts copied form other places where the references are changed so to point inside this document. The most important sources used are the W3C Recommendations (and candidates) for RDF(S) and the DAML+OIL reference description. Links to the original doucments and parts of them are available in the section headings, reference with text "link to the original".
The document was prepared in the course of the research for a DAML+OIL reasoner that is under development by OntoText Lab. as part of its contribution to the On-To-Knowledge project (IST-1999-10132).
| Contents |
1. RDF Model and Syntax
Specification
1.1. RDF Basic
Serialization Syntax
1.2. Basic
Abbreviated Syntax
1.3. Containers
1.4. Statements about
Statements
1.5. Formal Model for
RDF
1.6. Formal Grammar for
RDF
2. Resource Description Framework (RDF)
Schema
2.1. RDF Schemas
2.2. Classes and
Properties
2.3. Constraints
2.4. Documentation
2.5. Model and Syntax
concepts
2.6. RDF(S) XML
Serialization
3. Reference description of the
DAML+OIL (March 2001) ontology markup language
3.1. Abstract
3.2. Introductory
remarks
3.3. Header
3.4. Version
information
3.5. Imports
3.6. Objects and
Datatype Values
3.7. Class elements
3.8. Class
expressions
3.9.
Enumerations
3.10. Property
restrictions
3.11. Boolean
combination of class expressions
3.12. Property
elements
3.13. Axioms
3.14. Instances
3.15. Datatype
values
3.16.
rdf:parseType="daml:collection"
3.17. Index of all
language elements
3.18. Notes
4. RDF Schema definition of
DAML+OIL
5. Classification of the resources in a DAML+OIL ontology
5.1. DAML+OIL Headers
5.2. DAML+OIL Class elements
5.3. DAML+OIL Property elements
5.4. Instances
5.5. Others
6. DAML+OIL class definitions as RDF graphs
| 1. RDF Model and Syntax Specification |
The following definitions are taken from the document Resource Description Framework (RDF) Model and Syntax Specification.
| 1.1. RDF Basic Serialization Syntax [link to the original] |
Basic RDF serialization syntax takes the form:
[1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
[2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt*
'</rdf:Description>'
[3] idAboutAttr ::= idAttr | aboutAttr
[4] aboutAttr ::= 'about="' URI-reference '"'
[5] idAttr ::= 'ID="' IDsymbol '"'
[6] propertyElt ::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr '/>'
[7] propName ::= Qname
[8] value ::= description | string
[9] resourceAttr ::= 'resource="' URI-reference '"'
[10] Qname ::= [ NSprefix ':' ] name
[11] URI-reference ::= string, interpreted per [URI]
[12] IDsymbol ::= (any legal XML name symbol)
[13] name ::= (any legal XML name symbol)
[14] NSprefix ::= (any legal XML namespace prefix)
[15] string ::= (any XML text, with "<", ">", and "&" escaped)
The RDF element is a simple wrapper that marks the boundaries in an XML document between which the content is explicitly intended to be mappable into an RDF data model instance. The RDF element is optional if the content can be known to be RDF from the application context.
Description contains the remaining elements that cause the creation of statements in the model instance. The Description element may be thought of (for purposes of the basic RDF syntax) as simply a place to hold the identification of the resource being described. Typically there will be more than one statement made about a resource; Description provides a way to give the resource name just once for several statements.
When the about attribute is specified with Description, the statements in the Description refer to the resource whose identifier is determined from the about. The value of the about attribute is interpreted as a URI-reference per Section 4 of [URI]. The corresponding resource identifier is obtained by resolving the URI-reference to absolute form as specified by [URI]. If a fragment identifier is included in the URI-reference then the resource identifier refers only to the subcomponent of the containing resource that is identifed by the corresponding fragment id internal to that containing resource (see anchor in [Dexter94]), otherwise the identifier refers to the entire resource specified by the URI. A Description element without an about attribute represents a new resource. Such a resource might be a surrogate, or proxy, for some other physical resource that does not have a recognizable URI. The value of the ID attribute of the Description element, if present, is the anchor id of this "in-line" resource.
If another Description or property value needs to refer to the in-line resource it will use the value of the ID of that resource in its own about attribute. The ID attribute signals the creation of a new resource and the about attribute refers to an existing resource; therefore either ID or about may be specified on Description but not both together in the same element. The values for each ID attribute must not appear in more than one ID attribute within a single document.
A single Description may contain more than one propertyElt element with the same property name. Each such propertyElt adds one arc to the graph. The interpretation of this graph is defined by the schema designer.
Within a propertyElt, the resource attribute specifies that some other resource is the value of this property; that is, the object of the statement is another resource identified by URI rather than a literal. The resource identifier of the object is obtained by resolving the resource attribute URI-reference in the same manner as given above for the about attribute. Strings must be well-formed XML; the usual XML content quoting and escaping mechanisms may be used if the string contains character sequences (e.g. "<" and "&") that violate the well-formedness rules or that otherwise might look like markup. See Section 6. for additional syntax to specify a property value with well-formed XML content containing markup such that the markup is not interpreted by RDF.
Property names must be associated with a schema. This can be done by qualifying the element names with a namespace prefix to unambiguously connect the property definition with the corresponding RDF schema or by declaring a default namespace as specified in [NAMESPACES].
| 1.2. Basic Abbreviated Syntax [link to the original] |
While the serialization syntax shows the structure of an RDF model most clearly, often it is desirable to use a more compact XML form. The RDF abbreviated syntax accomplishes this. As a further benefit, the abbreviated syntax allows documents obeying certain well-structured XML DTDs to be directly interpreted as RDF models.
Three forms of abbreviation are defined for the basic serialization syntax. The first is usable for properties that are not repeated within a Description and where the values of those properties are literals. In this case, the properties may be written as XML attributes of the Description element.
The second RDF abbreviation form works on nested Description elements. This abbreviation form can be employed for specific statements when the object of the statement is another resource and the values of any properties given in-line for this second resource are strings. In this case, a similar transformation of XML element names into XML attributes is used: the properties of the resource in the nested Description may be written as XML attributes of the propertyElt element in which that Description was contained.
The third basic abbreviation applies to the common case of a Description element containing a type property (see Section 4.1 for the meaning of type). In this case, the resource type defined in the schema corresponding to the value of the type property can be used directly as an element name.
The EBNF for the basic abbreviated syntax replaces productions [2] and [6] of the grammar for the basic serialization syntax in the following manner:
[2a] description ::= '<rdf:Description' idAboutAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6a] propertyElt ::= '<' propName '>' value '</' propName '>'
| '<' propName resourceAttr? propAttr* '/>'
[16] propAttr ::= propName '="' string '"'
(with embedded quotes escaped)
[17] typedNode ::= '<' typeName idAboutAttr? propAttr* '/>'
| '<' typeName idAboutAttr? propAttr* '>'
property* '</' typeName '>'
| 1.3. Containers [link to the original] |
Frequently it is necessary to refer to a collection of resources; for example, to say that a work was created by more than one person, or to list the students in a course, or the software modules in a package. RDF containers are used to hold such lists of resources or literals.
RDF defines three types of container objects:
Container Syntax
RDF container syntax takes the form:
[18] container ::= sequence | bag | alternative [19] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' [20] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' [21] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' [22] member ::= referencedItem | inlineItem [23] referencedItem ::= '<rdf:li' resourceAttr '/>' [24] inlineItem ::= '<rdf:li>' value '</rdf:li>'
Containers may be used everywhere a Description is permitted:
[1a] RDF ::= '<rdf:RDF>' obj* '</rdf:RDF>' [8a] value ::= obj | string [25] obj ::= description | container
Note that RDF/XML uses li as a convenience element to avoid having to explicitly number each member. The li element assigns the properties _1, _2, and so on as necessary. The element name li was chosen to be mnemonic with the term "list item" from HTML.
An Alt container is required to have at least one member. This member will be identified by the property _1 and is the default or preferred value.
Containers Defined By A URI Pattern
One very frequent use of metadata is to make statements about "all pages at my Web site", or "all pages in this branch of my Web site". In many cases it is impractical or even undesirable to try to list each such resource explicitly and identify it as a member of a container. RDF therefore has a second distributive referent type. This second distributive referent type is a shorthand syntax that represents an instance of a Bag whose members are by definition all resources whose resource identifiers begin with a specified string:
[26a] aboutEachAttr ::= 'aboutEach="' URI-reference '"'
| 'aboutEachPrefix="' string '"'
The aboutEachPrefix attribute declares that there is a Bag whose members are all the resources whose fully resolved resource identifiers begin with the character string given as the value of the attribute. The statements in a Description that has the aboutEachPrefix attribute apply individually to each of the members of this Bag.
| 1.4. Statements about Statements [link to the original] |
In addition to making statements about Web resources, RDF can be used for making statements about other RDF statements; we will refer to these as higher-order statements. In order to make a statement about another statement, we actually have to build a model of the original statement; this model is a new resource to which we can attach additional properties.
Modeling Statements
Statements are made about resources. A model of a statement is the resource we need in order to be able to make new statements (higher-order statements) about the modeled statement.
To model statements RDF defines the following properties:
A new resource with the above four properties represents the original statement and can both be used as the object of other statements and have additional statements made about it. The resource with these four properties is not a replacement for the original statement, it is a model of the statement. A statement and its corresponding reified statement exist independently in an RDF graph and either may be present without the other. The RDF graph is said to contain the fact given in the statement if and only if the statement is present in the graph, irrespective of whether the corresponding reified statement is present.
Reification is also needed to represent explicitly in the model the statement grouping implied by Description elements. The RDF graph model does not need a special construct for Descriptions; since Descriptions really are collections of statements, a Bag container is used to indicate that a set of statements came from the same (syntactic) Description. Each statement within a Description is reified and each of the reified statements is a member of the Bag representing that Description.
Note the new attribute bagID. This attribute specifies the resource id of the container resource:
[2b] description ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
[27] bagIDAttr ::= 'bagID="' IDsymbol '"'
BagID and ID should not be confused. ID specifies the identification of an in-line resource whose properties are further detailed in the Description. BagID specifies the identification of the container resource whose members are the reified statements about another resource. A Description may have both an ID attribute and a bagID attribute.
| 1.5. Formal Model for RDF [link to the original] |
This specification shows three representations of the data model; as 3-tuples (triples), as a graph, and in XML. These representations have equivalent meaning. The mapping between the representations used in this specification is not intended to constrain in any way the internal representation used by implementations.
The RDF data model is defined formally as follows:
We can view a set of statements (members of Statements) as a directed labeled graph: each resource and literal is a vertex; a triple {p, s, o} is an arc from s to o, labeled by p.
This can be read either
o is the value of p for s
or (left to right)
s has a property p with a value o
or even
the p of s is o
The notation [I] denotes the resource identified by the URI I and quotation marks denote a literal.
From the standpoint of an RDF processor, facts (that is, statements) are triples that are members of Statements. Therefore, the original statement remains a fact despite it being reified since the triple representing the original statement remains in Statements. We have merely added four more triples.
The property named "type" is defined to provide primitive typing. The formal definition of type is:
|
Furthermore, the formal specification of reification is:
|
The resource r in the definition above is called the reified statement. When a resource represents a reified statement; that is, it has an RDF:type property with a value of RDF:Statement, then that resource must have exactly one RDF:subject property, one RDF:object property, and one RDF:predicate property.
As described in Section 3, it is frequently necessary to represent a collection of resources or literals; for example to state that a property has an ordered sequence of values. RDF defines three kinds of collections: ordered lists, called Sequences, unordered lists, called Bags, and lists that represent alternatives for the (single) value of a property, called Alternatives.
Formally, these three collection types are defined by:
|
To represent a collection c, create a triple {RDF:type, c, t} where t is one of the three collection types RDF:Seq, RDF:Bag, or RDF:Alt. The remaining triples {RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ... point to each of the members rn of the collection. For a single collection resource there may be at most one triple whose predicate is any given element of Ord and the elements of Ord must be used in sequence starting with RDF:_1. For resources that are instances of the RDF:Alt collection type, there must be exactly one triple whose predicate is RDF:_1 and that is the default value for the Alternatives resource (that is, there must always be at least one alternative).
| 1.6. Formal Grammar for RDF [link to the original] |
The complete BNF for RDF is reproduced here from previous sections. The precise interpretation of the grammar in terms of the formal model is also given. Syntactic features inherited from XML are not reproduced here. These include all well-formedness constraints, the use of whitespace around attributes and the '=', as well as the use of either double or single quotes around attribute values. This section is intended for implementors who are building tools that read and interpret RDF/XML syntax.
Where used below, the keywords "SHOULD", "MUST", and "MUST NOT" are to be interpreted as described in RFC 2119 [RFC2119]. However, for readability, these words do not appear in all uppercase letters in this specification.
[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
[6.2] obj ::= description | container
[6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6.4] container ::= sequence | bag | alternative
[6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr
[6.6] idAttr ::= ' ID="' IDsymbol '"'
[6.7] aboutAttr ::= ' about="' URI-reference '"'
[6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"'
| ' aboutEachPrefix="' string '"'
[6.9] bagIdAttr ::= ' bagID="' IDsymbol '"'
[6.10] propAttr ::= typeAttr
| propName '="' string '"' (with embedded quotes escaped)
[6.11] typeAttr ::= ' type="' URI-reference '"'
[6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>'
| '<' propName idAttr? parseLiteral '>'
literal '</' propName '>'
| '<' propName idAttr? parseResource '>'
propertyElt* '</' propName '>'
| '<' propName idRefAttr? bagIdAttr? propAttr* '/>'
[6.13] typedNode ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>'
| '<' typeName idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</' typeName '>'
[6.14] propName ::= Qname
[6.15] typeName ::= Qname
[6.16] idRefAttr ::= idAttr | resourceAttr
[6.17] value ::= obj | string
[6.18] resourceAttr ::= ' resource="' URI-reference '"'
[6.19] Qname ::= [ NSprefix ':' ] name
[6.20] URI-reference ::= string, interpreted per [URI]
[6.21] IDsymbol ::= (any legal XML name symbol)
[6.22] name ::= (any legal XML name symbol)
[6.23] NSprefix ::= (any legal XML namespace prefix)
[6.24] string ::= (any XML text, with "<", ">", and "&" escaped)
[6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
| '<rdf:Seq' idAttr? memberAttr* '/>'
[6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
| '<rdf:Bag' idAttr? memberAttr* '/>'
[6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
| '<rdf:Alt' idAttr? memberAttr? '/>'
[6.28] member ::= referencedItem | inlineItem
[6.29] referencedItem ::= '<rdf:li' resourceAttr '/>'
[6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>'
| '<rdf:li' parseLiteral '>' literal </rdf:li>'
| '<rdf:li' parseResource '>' propertyElt* </rdf:li>'
[6.31] memberAttr ::= ' rdf:_n="' string '"' (where n is an integer)
[6.32] parseLiteral ::= ' parseType="Literal"'
[6.33] parseResource ::= ' parseType="Resource"'
[6.34] literal ::= (any well-formed XML)
The formal namespace name for the properties and classes defined in this specification is http://www.w3.org/1999/02/22-rdf-syntax-ns#. When an RDF processor encounters an XML element or attribute name that is declared to be from a namespace whose name begins with the string "http://www.w3.org/TR/REC-rdf-syntax" and the processor does not recognize the semantics of that name then the processor is required to skip (i.e., generate no tuples for) the entire XML element, including its content, whose name is unrecognized or that has an attribute whose name is unrecognized.
Each propertyElt E contained by a Description element results in the creation of a triple {p,r,v} where:
The parseType attribute changes the interpretation of the element content. The parseType attribute should have one of the values 'Literal' or 'Resource'. The value is case-sensitive. The value 'Literal' specifies that the element content is to be treated as an RDF/XML literal; that is, the content must not be interpreted by an RDF processor. The value 'Resource' specifies that the element content must be treated as if it were the content of a Description element. Other values of parseType are reserved for future specification by RDF. With RDF 1.0 other values must be treated as identical to 'Literal'. In all cases, the content of an element having a parseType attribute must be well-formed XML. The content of an element having a parseType="Resource" attribute must further match the production for the content of a Description element.
The RDF Model and Syntax Working Group acknowledges that the parseType='Literal' mechanism is a minimum-level solution to the requirement to express an RDF statement with a value that has XML markup. Additional complexities of XML such as canonicalization of whitespace are not yet well defined. Future work of the W3C is expected to resolve such issues in a uniform manner for all applications based on XML. Future versions of RDF will inherit this work and may extend it as we gain insight from further application experience.
URI-References are resolved to resource identifiers by first resolving the URI-reference to absolute form as specified by [URI] using the base URI of the document in which the RDF statements appear. If a fragment identifier is included in the URI-reference then the resource identifier refers only to a subcomponent of the containing resource; this subcomponent is identifed by the corresponding anchor id internal to that containing resource and the extent of the subcomponent is defined by the fragment identifier in conjunction with the content type of the containing resource, otherwise the resource identifier refers to the entire item specified by the URI.
Note: Although non-ASCII characters in URIs are not allowed by [URI], [XML] specifies a convention to avoid unnecessary incompatibilities in extended URI syntax. Implementors of RDF are encouraged to avoid further incompatibility and use the XML convention for system identifiers. Namely, that a non-ASCII character in a URI be represented in UTF-8 as one or more bytes, and then these bytes be escaped with the URI escaping mechanism (i.e., by converting each byte to %HH, where HH is the hexadecimal notation of the byte value).
The Description element itself represents an instance of a Bag resource. The members of this Bag are the resources corresponding to the reification of each of the statements in the Description. If the bagID attribute is specified its value is the identifier of this Bag, else the Bag is anonymous.
When about is specified with Description, the statements in the Description refer to the resource named in the about. A Description element without an about attribute represents an in-line resource. This in-line resource has a resource identifier formed using the value of the base URI of the document containing the RDF statements plus an anchor id equal to the value of the ID attribute of the Description element, if present. When another Description or property value refers to the in-line resource it will use the value of the ID in an about attribute. When the other Description refers to the Bag of resources corresponding to the reified statements it will use the value of bagID in an about attribute. Either ID or about may be specified on Description but not both together in the same element. The values for each ID and bagID attribute must not appear in more than one such attribute within a document nor may the same value be used in an ID and a bagID within a single document.
When aboutEach is specified with Description, the statements in the Description refer to each of the members of the container named by aboutEach. The triples {p,r,v} represented by each contained propertyElt E as described above are duplicated for each r that is a member of the container.
When aboutEachPrefix is specified with Description, the statements in the Description refer to each of the members of an anonymous Bag container. The members of this Bag container are all the resources whose absolute form resource identifiers begin with the character string given as the value of aboutEachPrefix. The absolute form resource identifier is produced by resolving the URI according to the algorithm in Section 5.2., Resolving Relative References to Absolute Form, in [URI]. The triples {p,r,v} represented by each contained propertyElt E as described above are duplicated for each r that is a member of the container.
Seq, Bag, and Alt each represent an instance of a Sequence, Bag, or Alternative container resource type respectively. A triple {RDF:type,c,t} is created where c is the collection resource and t is one of RDF:Seq, RDF:Bag, or RDF:Alt. The members of the collection are denoted by li. Each li element E corresponds to one member of the collection and results in the creation of a triple {p,c,v} where:
The URI identifies (after resolution) the target resource; i.e., the resource to which the Description applies or the resource that is included in the container. The bagID attribute on a Description element and the ID attribute on a container element permit that Description or container to be referred to by other Descriptions. The ID on a container element is the name that is used in a resource attribute on a property element to make the collection the value of that property.
Within propertyElt (production [6.12]), the URI used in a resource attribute identifies (after resolution) the resource that is the object of the statement (i.e., the value of this property). The value of the ID attribute, if specified, is the identifier for the resource that represents the reification of the statement. If an RDF expression (that is, content with RDF/XML markup) is specified as a property value the object is the resource given by the about attribute of the contained Description or the (possibly implied) ID of the contained Description or container resource. Strings must be well-formed XML; the usual XML content quoting and escaping mechanisms may be used if the string contains character sequences (e.g. "<" and "&") that violate the well-formedness rules or that otherwise might look like markup. The attribute parseType="Literal" specifies that the element content is an RDF literal. Any markup that is part of this content is included as part of the literal and not interpreted by RDF.
It is recommended that property names always be qualified with a namespace prefix to unambiguously connect the property definition with the corresponding schema.
As defined by XML, the character repertoire of an RDF string is ISO/IEC 10646 [ISO10646]. An actual RDF string, whether in an XML document or in some other representation of the RDF data model, may be stored using a direct encoding of ISO/IEC 10646 or an encoding that can be mapped to ISO/IEC 10646. Language tagging is part of the string value; it is applied to sequences of characters within an RDF string and does not have an explicit manifestation in the data model.
Two RDF strings are deemed to be the same if their ISO/IEC 10646 representations match. Each RDF application must specify which one of the following definitions of 'match' it uses:
Note: The W3C I18N WG is working on a definition for string identity matching. This definition will most probably be based on canonical equivalences according to the Unicode standard and on the principle of early uniform normalization. Users of RDF should not rely on any applications matching using the canonical equivalents, but should try to make sure that their data is in the normalized form according to the upcoming definitions.
This specification does not state a mechanism for determining equivalence between literals that contain markup, nor whether such a mechanism is guaranteed to exist.
The xml:lang attribute may be used as defined by [XML] to associate a language with the property value. There is no specific data model representation for xml:lang (i.e., it adds no triples to the data model); the language of a literal is considered by RDF to be a part of the literal. An application may ignore language tagging of a string. All RDF applications must specify whether or not language tagging in literals is significant; that is, whether or not language is considered when performing string matching or other processing.
Attributes whose names start with "xmlns" are namespace declarations and do not represent triples in the data model. There is no specific data model representation for such namespace declarations.
Each property and value expressed in XML attribute form by productions [6.3] and [6.10] is equivalent to the same property and value expressed as XML content of the corresponding Description according to production [6.12]. Specifically; each XML attribute A specified with a Description start tag other than the attributes ID, about, aboutEach, aboutEachPrefix, bagID, xml:lang, or any attribute starting with the characters xmlns results in the creation of a triple {p,r,v} where:
Grammatically, production [6.11] is just a special case of the propName production [6.10]. The value of the type attribute is interpreted as a URI-reference and expanded in the same way as the value of the resource attribute. Use of [6.11] is equivalent to using rdf:type as an element (property) name together with a resource attribute.
The typedNode form (production [6.13]) may be used to represent instances of resources of specific types and to further describe those resources. A Description expressed in typedNode form by production [6.13] is equivalent to the same Description expressed by production [6.3] with the same ID, bagID, and about attributes plus an additional type property in the Description where the value of the type property is the resource whose identifier is given by the fully expanded and resolved URI corresponding to the typeName of the typedNode. Specifically, a typedNode represents a triple {RDF:type,n,t} where n is the resource whose identifier is given by the value of the about attribute (after resolution) or whose anchor id is given by the value of the ID attribute of the typedNode element, and t is the expansion of the namespace-qualified tag name. The remainder of the typedNode attributes and content is handled as for Description elements above.
Properties and values expressed in XML attribute form within an empty XML element E by productions [6.10] and [6.12] are equivalent to the same properties and values expressed as XML content of a single Description element D which would become the content of E. The referent of D is the value of the property identified by the XML element name of E according to productions [6.17], [6.2], and [6.3]. Specifically; each propertyElt start tag containing attribute specifications other than ID, resource, bagID, xml:lang, or any attribute starting with the characters xmlns results in the creation of the triples {p,r1,r2}, {pa1,r2,va1}, ..., {pan,r2,van} where
The value of the bagID attribute, if specified, is the identifier for the Bag corresponding to the Description D; else the Bag is anonymous.
| 2. Resource Description Framework (RDF) Schema |
The following text is taken from the document Resource Description Framework (RDF) Schema Specification 1.0.
| 2.1. RDF Schemas [link to the original] |
The Resource Description Framework (RDF) is a foundation for processing metadata; it provides interoperability between applications that exchange machine-understandable information on the Web. RDF uses XML to exchange descriptions of Web resources but the resources being described can be of any type, including XML and non-XML resources. RDF emphasizes facilities to enable automated processing of Web resources. RDF can be used in a variety of application areas, for example: in resource discovery to provide better search engine capabilities, in cataloging for describing the content and content relationships available at a particular Web site, page, or digital library, by intelligent software agents to facilitate knowledge sharing and exchange, in content rating, in describing collections of pages that represent a single logical "document", for describing intellectual property rights of Web pages, and for expressing the privacy preferences of a user as well as the privacy policies of a Web site. RDF with digital signatures will be key to building the "Web of Trust" for electronic commerce, collaboration, and other applications.
Descriptions used by these applications can be modeled as relationships among Web resources. The RDF data model, as specified in [RDFMS], defines a simple model for describing interrelationships among resources in terms of named properties and values. RDF properties may be thought of as attributes of resources and in this sense correspond to traditional attribute-value pairs. RDF properties also represent relationships between resources. As such, the RDF data model can therefore resemble an entity-relationship diagram. The RDF data model, however, provides no mechanisms for declaring these properties, nor does it provide any mechanisms for defining the relationships between these properties and other resources. That is the role of RDF Schema.
| 2.2. Classes and Properties [link to the original] |
An RDF Schema is expressed by the data model described in the RDF Model and Syntax [RDFMS] specification. The schema description language is simply a set of resources and properties defined by the RDF Schema Specification and implicitly part of every RDF model using the RDF schema machinery.
This document specifies the RDF Schema mechanism as a set of RDF resources (including classes and properties), and constraints on their relationships.
The Type System
The RDF Schema defined in this specification is a collection of RDF resources
that can be used to describe properties of other RDF resources (including
properties) which define application-specific RDF vocabularies. The core schema
vocabulary is defined in a namespace informally called 'rdfs' here,
and identified by the URI reference
http://www.w3.org/2000/01/rdf-schema#. This specification also uses
the prefix 'rdf' to refer to the core RDF namespace
http://www.w3.org/1999/02/22-rdf-syntax-ns#.
As described in the RDF Model and Syntax specification [RDFMS], resources may be
instances of one or more classes; this is indicated with the
rdf:type property. Classes themselves are often organized in a
hierarchical fashion, for example a class Dog might be considered a
subclass of Mammal which is a subclass of Animal,
meaning that any resource which is of rdf:type Dog is
also considered to be of rdf:type Animal. This
specification describes a property, rdfs:subClassOf, to denote such
relationships between classes.
The RDF Schema type system is similar to the type systems of object-oriented
programming languages such as Java. However, RDF differs from many such systems
in that instead of defining a class in terms of the properties its instances may
have, an RDF schema will define properties in terms of the classes of resource
to which they apply. This is the role of the rdfs:domain and
rdfs:range constraints described in Section 3.
This specification anticipates the development of a set of classes
corresponding to a set of datatypes. This specification does not define any
specific datatypes, but does note that datatypes may be used as the value of the
rdfs:range property.
Core Classes
The following resources are the core classes that are defined as part of the RDF Schema vocabulary. Every RDF model that draws upon the RDF Schema namespace (implicitly) includes these.
rdfs:Resource
All things being described by RDF expressions are called resources,
and are considered to be instances of the class rdfs:Resource. The
RDF class rdfs:Resource represents the set called 'Resources' in
the formal model for RDF presented in section 5 of the Model and Syntax
specification [RDFMS].
rdf:Property
rdf:Property represents the subset of RDF resources that are
properties, i.e., all the elements of the set introduced as 'Properties' in
section 5 of the Model and Syntax specification [RDFMS].
rdfs:Class
This corresponds to the generic concept of a Type or
Category, similar to the notion of a Class in object-oriented
programming languages such as Java. When a schema defines a new class, the
resource representing that class must have an rdf:type property
whose value is the resource rdfs:Class. RDF classes can be defined
to represent almost anything, such as Web pages, people, document types,
databases or abstract concepts.
Core Properties
Every RDF model which uses the schema mechanism also (implicitly) includes
the following core properties. These are instances of the
rdf:Property class and provide a mechanism for expressing
relationships between classes and their instances or superclasses.
rdf:type
This indicates that a resource is a member of a class, and thus has all the
characteristics that are to be expected of a member of that class. When a
resource has an rdf:type property whose value is some specific
class, we say that the resource is an instance of the specified class.
The value of an rdf:type property for some resource is another
resource which must be an instance of rdfs:Class. The resource
known as rdfs:Class is itself a resource of rdf:type
rdfs:Class. Individual classes (for example, 'Dog') will always
have an rdf:type property whose value is rdfs:Class
(or some subclass of rdfs:Class, as described in section 2.3.2). A
resource may be an instance of more than one class.
rdfs:subClassOf
This property specifies a subset/superset relation between classes. The
rdfs:subClassOf property is transitive. If class A is a subclass of
some broader class B, and B is a subclass of C, then A is also implicitly a
subclass of C. Consequently, resources that are instances of class A will also
be instances of C, since A is a sub-set of both B and C. Only instances of
rdfs:Class can have the rdfs:subClassOf property and
the property value is always of rdf:type rdfs:Class. A
class may be a subclass of more than one class.
A class can never be declared to be a subclass of itself, nor of any of its own subclasses. Note that this constraint is not expressible using the RDF Schema constraint facilities provided below, and so does not appear in the RDF version of this specification given in Appendix A.
rdfs:subPropertyOf
The property rdfs:subPropertyOf is an instance of
rdf:Property that is used to specify that one property is a
specialization of another. A property may be a specialization of zero, one or
more properties. If some property P2 is a subPropertyOf another
more general property P1, and if a resource A has a P2 property with a value B,
this implies that the resource A also has a P1 property with value B.
A property can never be declared to be a subproperty of itself, nor of any of its own subproperties. Note that this constraint is not expressible using the RDF Schema constraint facilities provided below, and so does not appear in the RDF version of this specification given in Appendix A.
rdfs:seeAlso
The property rdfs:seeAlso specifies a resource that might
provide additional information about the subject resource. This property may be
specialized using rdfs:subPropertyOf to more precisely indicate the
nature of the information the object resource has about the subject resource.
The object and the subject resources are constrained only to be
instances of the class rdfs:Resource.
rdfs:isDefinedBy
The property rdfs:isDefinedBy is a subproperty of
rdfs:seeAlso, and indicates the resource defining the subject
resource. As with rdf:seeAlso, this property can be applied to any
instance of rdfs:Resource and may have as its value any
rdfs:Resource.
The most common anticipated usage is to identify an RDF schema, given a name for one of the properties or classes defined by that schema. Although XML namespace declarations will typically provide the URI where RDF vocabulary resources are defined, there are cases where additional information is required.
For example, constructs such as <rdfs:subPropertyOf
rdf:resource="http://purl.org/dc/elements/1.0/Creator"/>
do not
indicate the URI of the schema that includes the vocabulary item
Creator (i.e., http://purl.org/dc/elements/1.0/).
In such cases, the rdfs:isDefinedBy property can be used to
explicitly represent that information. This approach will also work when the
URIs of the namespace and its components have no obvious relationship, as would
be the case if they were identified using schemes such as GUIDs or MD-5 hashes.
| 2.3. Constraints [link to the original] |
This specification introduces an RDF vocabulary for making statements about constraints on the use of properties and classes in RDF data. For example, an RDF schema might describe limitations on the types of values that are valid for some property, or on the classes to which it makes sense to ascribe such properties.
RDF Schema provides a mechanism for describing such constraints, but does not say whether or how an application must process the constraint information.
Core Constraints
rdfs:ConstraintResource
This resource defines a subclass of rdfs:Resource whose
instances are RDF schema constructs involved in the expression of constraints.
The purpose of this class is to provide a mechanism that allows RDF processors
to assess their ability to use the constraint information associated with an RDF
model. Since this specification does not provide a mechanism for the dynamic
discovery of new forms of constraint, an RDF Schema 1.0 processor encountering
previously unknown instances of rdfs:ConstraintResource can be sure
that it is unqualified to determine the meaning of those constraints.
3.1.2. rdfs:ConstraintProperty
This resource defines a subclass of rdf:Property, all of whose
instances are properties used to specify constraints. This class is a subclass
of rdfs:ConstraintResource and corresponds to the subset of that
class representing properties. Both rdfs:domain and
rdfs:range are instances of rdfs:ConstraintProperty.
3.1.3. rdfs:range
An instance of ConstraintProperty that is used to indicate the
class(es) that the values of a property must be members of. The value of a
range property is always a Class. Range constraints
are only applied to properties.
A property can have at most one range property. It is possible for it to have no range, in which case the class of the property value is unconstrained.
Constraints on rdfs:range
The rdfs:domain of rdfs:range is the class
rdf:Property. This indicates that the range property
applies to resources that are themselves properties.
The rdfs:range of rdfs:range is the class
rdfs:Class. This indicates that any resource that is the value of a
range property will be a class.
rdfs:domain
An instance of ConstraintProperty that is used to indicate the
class(es) on whose members a property can be used.
A property may have zero, one, or more than one class as its domain. If there is no domain property, it may be used with any resource. If there is exactly one domain property, it may only be used on instances of that class (which is the value of the domain property). If there is more than one domain property, the constrained property can be used with instances of any of the classes (that are values of those domain properties).
Constraints on rdfs:domain
The rdfs:domain of rdfs:domain is the class
rdf:Property. This indicates that the domain property is used on
resources that are properties.
The rdfs:range of rdfs:domain is the class
rdfs:Class. This indicates that any resource that is the value of a
domain property will be a class.
Note: This specification does not constraint the number ofrdfs:domainproperties that a property may have. If there is nodomainproperty, we know nothing about the classes with which the property is used. If there is more than onerdfs:domainproperty, the constrained property can be used with resources that are members of any of the indicated classes. Note that unlikerangethis is a very weak constraint.
| 2.4. Documentation [link to the original] |
The following properties are provided to support simple documentation and
user-interface related annotations within RDF schemas. Multilingual
documentation of schemas is supported at the syntactic level through use of the
xml:lang language tagging facility. Since RDF schemas are expressed
within the RDF data model, vocabularies defined in other namespaces may be used
to provide richer documentation.
rdfs:comment
This is used to provide a human-readable description of a resource.
rdfs:label
This is used to provide a human-readable version of a resource name.
| 2.5. Model and Syntax concepts [link to the original] |
The RDF Model and Syntax specification [RDFMS] introduces the base
concepts of RDF. A number of these are defined formally in the RDF Schema whose
namespace URI is http://www.w3.org/1999/02/22-rdf-syntax-ns#. In
addition, some further concepts are introduced in the RDF Model and Syntax
specification but do not appear in the RDF Model and Syntax schema. These
formally belong in the Schema namespace (for example, rdfs:Literal
and rdfs:Resource). In cases where an RDF resource belongs to the
http://www.w3.org/1999/02/22-rdf-syntax-ns# namespace, this
document can provide only a convenience copy of that resource's definition.
Appendix A provides an
RDF/XML schema for the RDF resources defined in this document, including RDF
Model concepts such as Literal and Resource. The
RDF/XML Schema in Appendix A also makes RDF statements about resources defined
in the RDF Model and Syntax namespace. These have the status of
annotations rather than definitions.
rdfs:Literal
This corresponds to the set called the 'Literals' in the formal model for RDF presented in section 5 of the Model and Syntax specification [RDFMS]. Atomic values such as textual strings are examples of RDF literals.
rdf:Statement
This corresponds to the set called the 'Statement' in the formal model for RDF presented in section 5 of the Model and Syntax specification [RDFMS].
rdf:subject
This corresponds to the property called the 'subject' in the formal model for
RDF presented in section 5 of the Model and Syntax specification [RDFMS]. Its
rdfs:domain is rdf:Statement and
rdfs:range is rdfs:Resource. This is used to specify
the resource described by a reified statement.
rdf:predicate
This corresponds to the property called the 'predicate' in the formal model
for RDF presented in section 5 of the Model and Syntax specification [RDFMS]. Its
rdfs:domain is rdf:Statement and
rdfs:range is rdf:Property. This is used to identify
the property used in the modeled statement.
rdf:object
This corresponds to the property called the 'object' in the formal model for
RDF presented in section 5 of the Model and Syntax specification [RDFMS]. Its rdfs:domain is
rdf:Statement. This is used to identify the property value in the
modeled statement.
rdfs:Container
This class is used to represent the Container classes described in section 3
of the Model and Syntax specification [RDFMS]. It is an instance of
rdfs:Class and rdfs:subClassOf of
rdfs:Resource.
rdf:Bag
This corresponds to the class called 'Bag' in the formal model for RDF
presented in section 5 of the Model and Syntax specification [RDFMS]. It is an instance of
rdfs:Class and rdfs:subClassOf
rdfs:Container.
rdf:Seq
This corresponds to the class called 'Sequence' in the formal model for RDF
presented in section 5 of the Model and Syntax specification [RDFMS]. It is an instance of
rdfs:Class and rdfs:subClassOf
rdfs:Container.
rdf:Alt
This corresponds to the class called 'Alternative' in the formal model for
RDF presented in section 5 of the Model and Syntax specification [RDFMS]. It is an instance of
rdfs:Class and rdfs:subClassOf
rdfs:Container.
rdfs:ContainerMembershipProperty
This class has as members the properties _1, _2, _3 ... used to
indicate container membership, as described in section 3 of the Model and Syntax
specification [RDFMS]. This
is a rdfs:subClassOf rdf:Property.
rdf:value
This corresponds to the 'value' property described in section 2.3 of the Model and Syntax specification [RDFMS].
| 2.6. RDF(S) XML Serialization [link to the original] |
An RDF specification of the core RDF Schema model is given here in RDF/XML serialization syntax. Please note that the namespace URI for the RDF Schema Specification will change in future versions of this specification if the schema changes. This RDF schema includes annotations describing RDF resources defined formally in the RDF Model and Syntax specification, as well as definitions for new resources belonging to the RDF Schema namespace.
Note that there are some constraints (such as those given in 2.3.2 above) on certain RDF Schema resources which are themselves not fully expressible using the RDF Schema specification. For example, the RDF below does not tell us that subClassOf arcs should not (to use terminology from the nodes and arcs representation) form loops in any RDF model.
|
| 3. Reference description of the DAML+OIL (March 2001) ontology markup language |
The following definitions are taken from the document Reference description of the DAML+OIL (March 2001) ontology markup language.
| 3.1. Abstract [link to the original] |
DAML+OIL is a semantic markup language for Web resources. It builds on earlier W3C standards such as RDF and RDF Schema, and extends these languages with richer modelling primitives. DAML+OIL provides modelling primitives commonly found in frame-based languages. DAML+OIL (March 2001) extends DAML+OIL (December 2000) with values from XML Schema datatypes. The language has a clean and well defined semantics.
This document gives a systematic, compact and informal description of all the modelling primitives of DAML+OIL (March 2001). We expect this document to serve as a reference guide for users of the DAML+OIL language.
| 3.2. Introductory remarks [link to the original] |
A DAML+OIL knowledge base is a collection of RDF triples. DAML+OIL prescribes a specific meaning for triples that use the DAML+OIL vocabulary. This document informally specifies which collections of RDF triples constitute the DAML+OIL vocabulary and what the prescribed meaning of such triples is.
As with any set of RDF triples, DAML+OIL triples can be represented in many different syntactic forms (as described in the RDF specification). The current document uses a specific RDF syntactic form for these triples. However, it is also allowed to use any other syntactic RDF form that results in the same underlying set of RDF triples as the syntax used in this document. Such other syntactic form would then carry exactly the same prescribed meaning as the equivalent syntactic form used in this document. See Syntax Note for an example of this.
As stated above, DAML+OIL assigns a specific meaning to certain RDF triples. The model-theoretic semantics specifies exactly which triples are assigned a specific meaning, and what this meaning is. DAML+OIL only provides a semantic interpretation for those parts of an RDF graph that instantiate the schema defined in daml+oil.daml. Any additional RDF statements, resulting in additional RDF triples are perfectly allowed, but DAML+OIL is silent on the semantic consequences (or lack thereof) of such additional triples. See Mixing Note for an example of this. The KIF axiomatization provides a meaning for all RDF triples, but non DAML+OIL triples are only modelled as triples, nothing deeper.
A DAML+OIL ontology is made up of several components, some of which are optional, and some of which may be repeated. See the index for a listing of all these components. Througout this document, DAML+OIL constructs will be presented in a structured format, and not as bare RDF triples. This structured RDF format is more natural to read, but, of course, any way of generating the same RDF triples as generated by the structured RDF format is equivalent.
A DAML+OIL ontology consists of zero or more headers, followed by zero or more class elements, property elements, and instances.
| 3.3. Header [link to the original] |
An daml:Ontology
element contains zero or more version
information and imports elements.
<Ontology rdf:about=""> <versionInfo>$Id: daml-oil-syntax.htm,v 1.1 2003/03/05 10:05:16 borislav Exp $</versionInfo> <rdfs:comment>An example ontology</rdfs:comment> <imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/> </Ontology>
| 3.4. Version information [link to the original] |
The
daml:versionInfo element generally contains a string giving
information about this version, for example RCS/CVS keywords. This element does
not contribute to the logical meaning of the ontology. See the example
above.
| 3.5. Imports [link to the original] |
Each
daml:imports statement references another DAML+OIL ontology
containing definitions that apply to the current DAML+OIL resource. Each
reference consists of a URI specifying from where the ontology is to be imported
from. See the example above. Imports statements are transitive,
that is, if ontology A imports B, and B imports C, then A imports both B and C.
Importing an ontology into itself is considered a null action, so if ontology A
imports B and B imports A, then they are considered to be equivalent.
Note that namespaces only provide a mechanism for creating unique names for elements, and do not actually include definitions in the way that imports does. Similarly, imports statements do not set up a shorthand notation for names. Therefore, it is common to have imports statements that correspond to each namespace. However, additional imports may be used for ontologies that provide definitions without introducing any new names.
| 3.6. Objects and Datatype Values [link to the original] |
DAML+OIL divides the universe into two disjoint parts. One part consists of the values that belong to XML Schema datatypes. This part is called the datatype domain. The other part consists of (individual) objects that are considered to be members of classes described within DAML+OIL (or RDF). This part is called the object domain.
DAML+OIL is mostly concerned with the creation of classes that describe (or define) part of the object domain. Such classes are called object classes and are elements of daml:Class, a subclass of rdfs:Class. DAML+OIL (March 2001) also allows the use of XML Schema datatypes to describe (or define) part of the datatype domain. These datatypes are used within DAML+OIL simply by including their URIs within a DAML+OIL ontology. They are (implicitly) elements of daml:Datatype. Datatypes are not DAML+OIL individual objects.
| 3.7. Class elements [link to the original] |
A class element,
daml:Class, contains (part of) the definition of an object class.
A class element refers to a class name (a URI), (we will refer to this
class as C) and contains
rdfs:subClassOf elements (each containing a class-expression).
daml:disjointWith elements (each containing a class-expression).daml:disjointUnionOf elements (each containing a list of class-expressions).daml:sameClassAs elements (each containing a class-expression).daml:equivalentToelements
(each containing a class
expression)Notice that the first two elements state necessary but not sufficient
conditions for class membership. The final four elements state both necessary
and sufficient conditions.
| 3.8. Class expressions [link to the original] |
A class expression is the name used in this document for either
<daml:Class>...</daml:Class> tags, or
<rdfs:Class>...</rdfs:Class> tags Each class expression either refers to a named class, namely the class that is identified by the URI, or implicitly defines an anonymous class, respectively the class that contains exactly the enumerated elements, or the class of all instances which satisfy the property-restriction, or the class that satisfies the boolean combination of such expressions.
Two class names are already predefined, namely the classes daml:Thing and daml:Nothing. Every
object is a member of daml:Thing, and no object is a member
daml:Nothing. Consequently, every class is a subclass of
daml:Thing and daml:Nothing is a subclass of every
class.
| 3.9. Enumerations [link to the original] |
An enumeration is a
daml:oneOf element, containing a list of the objects that are its
instances.
This enables us to define a class by exhaustively enumerating its elements.
The class defined by the oneOf element contains exactly the enumerated elements,
no more, no less. For example:
<daml:oneOf parseType="daml:collection"> <daml:Thing rdf:about="#Eurasia"/> <daml:Thing rdf:about="#Africa"/> <daml:Thing rdf:about="#North_America"/> <daml:Thing rdf:about="#South_America "/> <daml:Thing rdf:about="#Australia"/> <daml:Thing rdf:about="#Antarctica"/> </oneOf>
| 3.10. Property restrictions [link to the original] |
A property restriction is a special kind of class expression. It implicitly defines an anonymous class, namely the class of all objects that satisfy the restriction. There are two kinds of restrictions. The first kind, ObjectRestriction, works on object properties, i.e., properties that relate objects to other objects. The second kind, DatatypeRestriction, works on datatype properties, i.e., properties that relate objects to datatype values. Both kinds of restrictions are created using the same syntax, with the usual difference being whether a class element or a datatype reference is used. It is also possible to create restrictions that are neither restrictions nor datatype restrictions, but these restrictions are not handled within DAML+OIL.
A daml:Restriction element contains an
daml:onProperty element, which refers to a property name (a URI)
(we will refer to this property as P) and one or more of the following
daml:toClass
element (which contains a class
expression ).daml:hasValue
element (which contains (a reference to) an individual
object or a datatype
value).daml:hasClass
element (which contains a class
expression or a datatype
references).daml:cardinality element.daml:maxCardinality element.daml:minCardinality element.daml:hasClassQ element,
containing a class
expression or a datatype
references:
daml:cardinalityQ element.daml:maxCardinalityQ element.daml:minCardinalityQ element.Of course a cardinality constraint is simply shorthand for a pair of
minCardinality and maxCardinality constraints with equal values of N (and
similarly for cardinalityQ).
Warning: in order to avoid "exposed content" (i.e.,
to hide DAML+OIL annotations from browsers), it is necessary to write
cardinality constraints in an alternative RDF format. See
Cardinality
Syntax Notefor an example of
this.
When there are multiple restrictions listed as part of a single Restriction element, the property P has to satisfy all of the restrictions (i.e., multiple restrictions are read as a conjunction).
Notice that the restrictedBy element which was associated with slot-restrictions in earlier versions of the language has now been removed, since it is completely synonymous with subClassOf.
| 3.11. Boolean combination of class expressions [link to the original] |
A boolean combination of class expressions can be constructed from:
daml:intersectionOf element, containing a list of class
expressions. daml:unionOf
element, containing a list of class
expressions. daml:complementOf element, containing a single class
expression.Note that arbitrarily complex combinations of these expressions can be formed.See Boolean Notefor an example of this.
| 3.12. Property elements [link to the original] |
A rdf:Property element refers to a property name (a URI) (to
which we will refer as P). Properties that are used in property
restrictions should be either properties, which relate objects to other objects,
and are instances of ObjectProperty; or datatype properties, which
relate objects to datatype values, and are instances of DatatypeProperty.
A property element contains:
rdfs:subPropertyOf elements, each containing a property
name.rdfs:domain
elements (each containing a class
expression).rdfs:range
elements (each containing a class
expression).daml:samePropertyAs elements (each containing a property
name).equivalentTo elements (each containing a
property name).daml:inverseOf elements (each containing a property name), for properties only.Instead of an object property or datatype property element, it is also possible to use any of the following elements, each of which assert additional information about the property:
daml:TransitiveProperty element, which is a
subclass of ObjectProperty.daml:UniqueProperty element.daml:UnambigousProperty element, which is a
subclass of ObjectProperty.Notice that UniqueProperty and UnambiguousProperty specify
global cardinality restrictions. That is, no matter what class the property is
applied to, the cardinality constraints must hold, unlike the various
cardinality properties used in property
restrictions, which are part of a class element, and are
only enforced on the property when applied to that class.
A property
is a binary relation that may or may not be defined in the ontology. If it is
not defined, then it is assumed to be a binary relation with no globally
applicable constraints, i.e. any pair with first element an object and second
element an object or datatype value could be an instance of the
property.
Warning: If a transitive property (or any of its
superproperties) is used in a cardinality constraint, then class consistency is
no longer necessarily decidable. Of course, UniqueProperty is a a particular
case of a cardinality constraint.
| 3.14. Instances [link to the original] |
Instances of both classes (i.e., objects) and of properties (i.e., pairs) are
written in RDF and RDF Schema syntax.
See the specification of these languages for more details on the various
syntactic forms that are allowed. Here we list just some of the most common
notations:
<continent rdf:ID="Asia"/> <rdf:Description rdf:ID="Asia"> <rdf:type> <rdfs:Class rdf:about="#continent"/> </rdf:type> </rdf:Description> <rdf:Description rdf:ID="India"> <is_part_of rdf:resource="#Asia"/> </rdf:Description>
There is no unique name assumption for objects in DAML+OIL. To state that
objects are the same, a daml:sameIndividualAs element is
used. (Note that daml:equivalentTo can be also used here, but
daml:sameIndividual is preferred. To state that objects are
distinct, a daml:differentIndividualFrom
element is used. The situation is different for datatype values, where XML
Schema Datatype identity is used.
| 3.15. Datatype Values [link to the original] |
Datatype values are written in a manner that is valid RDF syntax, but which is given a special semantics in DAML+OIL. The preferred method is to give a lexical representation of the value as a string, along with an XML Schema datatype that is used to provide the type of the value as well as the parsing mechanism to go from the string to the value itself. The XML Schema datatype is the rdf:type of the value, and the lexical representation is the rdf:value of the value. So the decimal 10.5 could be input as <xsd:decimal rdf:value="10.5"> provided that xsd was defined as the URI of the XML Schema Datatype specification.
As a nod to backward compatability, literals that occur outside this sort of construction are interpreted as any of the XML Schema Datatype values with this lexical representation. These values are mostly unusable unless some typing information is available, such as a range for a property.
The question of whether any XML Schema datatype can be used in such constructions, or whether only certain XML Schema dataypes can be so used (such as only the predefined datatypes), remains open.
| 3.16. rdf:parseType="daml:collection" [link to the original] |
DAML+OIL needs to represent unordered collections of items (also known as bags, or multisets) in a number of constructions, such as intersectionOf, unionOf, oneOf, disjointUnionOf and Disjoint. DAML+OIL exploits the rdf:parseType attribute to extend the syntax for RDF with a convenient notation for such collections. Whenever an element has the rdf:parseType attribute with value "daml:collection", the enclosed elements must be interpreted as elements in a list structure, constructed using the elements List, first, rest and nil.
For example, the statement
<oneOf rdf:parseType="daml:collection"> <Thing rdf:resource="#red"/> <Thing rdf:resource="#white"/> <Thing rdf:resource="#blue"/> </oneOf>
should be interpreted as the following construction (also known as a consed-pair construction, from Lisp-lore):
<List>
<first>
<Thing rdf:resource="#red">
</first>
<rest>
<List>
<first>
<Thing rdf:resource="#white">
</first>
<rest>
<List>
<first>
<Thing rdf:resource="#blue">
</first>
<rest>
<List rdf:resource="http://www.daml.org/2001/03/daml+oil#nil">
</rest>
</List>
</rest>
</List>
</rest>
</List>
Current RDF parsers (RDF specification of February '99) will not support the daml:collection parseType. In order to process DAML+OIL documents, such parsers will have to be extended, or a separate preprocessing stage is required which translates the first form above into the second before the DAM+OIL code is given as input to the RDF parser.
Note that structures of parseType daml:collection are intended to represent unordered collections, even though the RDF datastructure imposes a specific order on the elements.
| 3.17. Index of all language elements [link to the original] |
| 3.18. Notes [link to the original] |
<rdfs:Class ID="Continents"/>
However, the following RDF statement:
<rdf:Description ID="Continents"> <rdf:Type resource="http://www.w3.org/2000/01/rdf-schema#Class"/> </rdf:Description>
results in exactly the same set of RDF triples, and is
therefore perfectly allowed as a class definition.
Another example is the two notations that we discuss for
cardinality constraints below. Again, both these forms result in the same set of RDF triples,
and are thus equivalent.
<rdf:Description about="#Person">
<Creator>Ora Lassila</Creator>
</rdf:Description>
then the semantics don't say what this
means or what it would imply for instances of Person. (Beyond of course the
minimal Subject-Verb-Object semantics of RDF).
<Restriction> <onProperty rdf:resource="#father"/> <cardinality>1</cardinality> </Restriction>
we would have to write
<Restriction cardinality="1"> <onProperty rdf:resource="#father"/> </Restriction>
to avoid any exposed content. The cardinality elements are
the only ones for which this alternative notation is required to avoid exposed
content.(See the
section on abbreviated syntaxin the RDF specification for
more details on this notation)
.
<complementOf> <Class> <unionOf parseType="daml:collection"> <Class rdf:resource="#meat"/> <Class rdf:resource="#fish"/> </unionOf> </Class> </complementOf>
<Disjoint parseType="daml:collection">
<Class>
<unionOf parseType="daml:collection">
<Class rdf:resource="#meat"/>
<Class rdf:resource="#fish"/>
</unionOf>
</Class>
<Class>
<unionOf parseType="daml:collection">
<Class rdf:resource="#plant">
<Restriction>
<onProperty rdf:resource="#is_part_of">
<hasValue rdf:r