Structural Specification and Functional-Style Syntax

W3C Editor's Draft 2126 November 2008

This version:

http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081121/http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081126/

Latest editor's draft:

http://www.w3.org/2007/OWL/draft/owl2-syntax/

Previous version:

http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081008/http://www.w3.org/2007/OWL/draft/ED-owl2-syntax-20081121/ (color-coded diff)

Editors:

Boris Motik, Oxford University

Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent

Bijan Parsia, University of Manchester

Contributors:

Ian Horrocks, Oxford University

Note: The complete list of contributors is being compiled and will be included in the next draft.

---

Copyright © 2008 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

Status of this Document

May Be Superseded

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

Set of Documents

This document is being published as one of a set of 11 documents:

1. Structural Specification and Functional-Style Syntax (this document)
2. Direct Semantics
3. RDF-Based Semantics
4. Conformance and Test Cases
5. Mapping to RDF Graphs
6. XML Serialization
7. Profiles
8. Quick Reference Guide
9. New Features &and Rationale
10. Manchester Syntax
11. rdf:text: A Datatype for Internationalized Text

Please Comment By 2008-11-252008-11-28

The OWL Working Group seeks public feedback on these Working Drafts. Please send your comments to public-owl-comments@w3.org (public archive). If possible, please offer specific changes to the text that would address your concern. You may also wish to check the Wiki Version of this document for internal-review comments and changes being drafted which may address your concerns.

No Endorsement

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

Patents

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

[Show Short TOC]

[Show Full TOC]

1.1 Normative Status of this DocumentThis document defines the structural specification of OWL 2, the functional syntax for OWL 2, and the behavior of datatype maps. Only the parts of the document related to these three purposes are normative. The examples in this document are informative and any part of the document that is specifically identified as informative is not normative. Finally, the informal descriptions of the semantics of OWL 2 constructs in this document are informative; the semantics is precisely specified in a separate document [OWL 2 Direct Semantics].

The italicized keywords MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY specify certain aspects of the normative behavior of OWL 2 tools, and are interpreted as specified in RFC 2119 [RFC 2119].

The structural specification of OWL 2 is defined using the Unified Modeling Language (UML) [UML], and the notation used is compatible with the Meta-Object Facility (MOF) [MOF]. This document uses only a very simple form of UML class diagrams that are expected to be intuitivelyeasily understandable toby readers who are familiar with the basic concepts of object-oriented systems, even if they are not familiar with UML. The names of abstract classes (i.e., classes that are not intended to be instantiated) are written in italic.

Elements of the structural specification are connected by associations, many of which are of the one-to-many type. Associations whose name is preceded by / are derived — that is, their value is determined based on the value of other associations and attributes. Whether the elements participating in associations are ordered and whether repetitions are allowed is made clear by the following standard UML conventions:

• By default, all associations are sets; that is, the elements in them are unordered and repetitions are disallowed.
• The { ordered,nonunique } attribute is placed next to the association ends that are ordered and in which repetitions are allowed. Such associations have the semantics of lists.

Whether two elements of the structural specification are considered to be the same is captured by the notion of structural equivalence, defined as follows. Elements o₁ and o₂ are structurally equivalent if and only if the following conditions hold:

• If o₁ and o₂ are atomic values, such as strings, integers, or IRIs (URIs), they are structurally equivalent if they are identical according to the notion of identity specified by the respective atomic type.
• If o₁ and o₂ are unordered associations without repetitions, they are structurally equivalent if each element of o₁ is structurally equivalent to some element of o₂ and vice versa.
• If o₁ and o₂ are ordered associations with repetitions, they are structurally equivalent if they contain the same number of elements and each element of o₁ is structurally equivalent to the element of o₂ with the same index.
• If o₁ and o₂ are complex elements consisting of other elements, they are structurally equivalent if
  • both o₁ and o₂ are of the same type,
  • each element of o₁ is structurally equivalent to the corresponding element of o₂, and
  • each association of o₁ is structurally equivalent to the corresponding association of o₂.

Note that structural equivalence is not a semantic notion, as it is based only on comparing structures.

Although set associations are widely used in the specification, sets written in one of the linear syntaxes (e.g., XML or RDF/XML) are not necessarily expected to be duplicate free. Duplicates SHOULD be eliminated from such constructs during parsing.

Ontologies and their elements are identified using International Resource Identifiers (IRIs) [RFC3987]. OWL 1 uses Uniform Resource Identifiers (URIs) as identifiers. To avoid introducing new terminology, this specification hereafter uses the term "URI" to mean "IRI". In the structural specification, IRIs are represented by the URI class. All IRIs in this specification are written using the grammar described below.

Thus,An IRI can be written as a full IRI. The < (U+3C) and > (U+3E) characters surrounding a full IRI are not part of the IRI, orbut are used solely for quotation purposes, identifying an IRI as a full IRI.

Alternatively, an IRI it can be abbreviated as a CURIE [CURIE]. To facilitate the latter,this end, commonly used IRIs — called namespaces — are associated with a prefix. An IRI U belongs to a namespace NU if, in their string representation, NU is a prefix of U; the part of U not covered by NU is called a reference of U w.r.t. NU. A URI U belonging to a namespace NU associated with a prefix pref is then commonly abbreviated as a CURIE pref:ref, where ref is the reference of U w.r.t. NU. CURIEs are not represented in the structural specification of OWL 2: if a concrete syntax of OWL 2 uses CURIEs to abbreviate long IRIs, these abbreviations MUST be expanded into full IRIs during parsing according to the rules of the respective syntax.

Table 2 defines the standard namespaces and the respective prefixes used throughout this specification.

IRIs belonging to the rdf, rdfs, xsd, and owl namespaces constitute the reserved vocabulary of OWL 2. As described in the following sections, the IRIs from the reserved vocabulary that are listed in Table 3 have special treatment in OWL 2. All IRIs from the reserved vocabulary not listed in Table 3 constitute the disallowed vocabulary of OWL 2 and MUST NOT be used in OWL 2 to name entities, ontologies, or ontology versions.

Characters and strings are defined in the same way as in [RDF:TEXT]. A character is an atomic unit of communication. The structure of characters is not further specified in OWL 2, other than to note that each character has a Universal Character Set (UCS) code point [ISO/IEC 10646]. The set of available characters is assumed to be infinite, and is thus independent from the currently actual version of UCS. A string is a finite sequence of characters, and the length of a string is the number of characters in it. In this document, strings are written as specified in [RDF:TEXT]: they are enclosed in double quotes,quotes (U+22), and a subset of the escaping mechanism of the N-triples specification [RDF Test Cases] is used to encode strings containing quotes.

Language tags are nonempty strings as defined in BCP 47 [BCP 47]. In this document, language tags are not enclosed in double quotes; however, this does not lead to parsing problems since, according to BCP 47, language tags contain neither whitespace nor the parenthesis characters ( (U+28) and ) (U+29).

Node IDs are borrowed from the N-Triples specification [RDF Test Cases].

An OWL 2 ontology is the main partan instance O of the Ontology class from the structural specification, and its structure isspecification of OWL 2 shown in Figure 1.1 that satisfies certain conditions given below. The main component of an OWL 2 ontology is its set of axioms, the structure of which is described in more detail in Section 9. Because the association between an ontology and its axioms is a set, an ontology cannot contain two axioms that are structurally equivalent. Apart from the axioms, ontologies can also contain ontology annotations (as described in more detail in Section 3.5), and they can also import other ontologies (as described in Section 3.4).

3.1 Ontology URI and Version URI Each ontology MAY have an ontology URI , whichThe following list summarizes all the conditions that O is usedrequired to identifysatisfy to be an OWL 2 ontology.

• If an ontology has an ontology URI,O MUST satisfy the restrictions on the presence of the ontology MAY additionally have aURI and version URI , whichfrom Section 3.1;
• O SHOULD satisfy the constraints on the uniqueness of the ontology URI and version URI from Section 3.1;
• O SHOULD satisfy the restrictions on the import closure from Section 3.4;
• each entity in O MUST have a URI satisfying the restrictions on the usage of the reserved vocabulary from Sections 5.1–5.6;
• each datatype in O MUST satisfy the restriction from Section 5.2;
• each literal in O MUST satisfy the restriction from Section 5.7;
• O MUST satisfy the typing constraints from Section 5.8.1;
• each DatatypeRestriction in O MUST satisfy the restriction from Section 7.5;
• each DataSomeValuesFrom and DataAllValuesFrom class expression in O MUST satisfy the restrictions from Section 8.4.1 and Section 8.4.2;
• each DataPropertyRange axiom in O MUST satisfy the restriction from Section 9.3.5;
• O MUST satisfy the global restriction from Section 11; and
• each O' directly imported into O MUST satisfy all of these restrictions as well.

An instance O of the Ontology class MAY have consistent declarations as specified in Section 5.8.2; however, this is not strictly necessary to make O an OWL 2 ontology.

3.2.1 Functional-Style Syntax Ontology Documents A functional-style syntaxThe ontology document is a sequenceof Unicode characters [ UNICODE ]an ontology O SHOULD be accessible from some URIthe URIs determined by means ofthe standard protocols. A functional-style syntax ontology document SHOULD use the UTF-8 encoding [ RFC3629 ]; its text MUST must match the ontologyDocument production of the grammar defined in this specification document; andfollowing rules:

• If O does not contain an ontology URI (and, consequently, it MUST be possible to convertdoes not contain a version URI either), then the ontology document intoof O MAY be accessible from any URI.
• If O contains an ontology by meansURI OU but no version URI, then the ontology document of O SHOULD be accessible from the canonical parsing process described in Section 5.8.3URI OU.
• ontologyDocument := { prefixDefinition } Ontology prefixDefinition := 'Namespace' '(' [ prefix ] '=' namespace ')'If D contains an ontology := 'Ontology' '(' [ ontologyURI [ versionURI ] ] directlyImportsDocuments ontologyAnnotations axioms ')' ontologyURI := URI versionURI :=URI directlyImportsDocuments := { 'Import' '('OU and a version URI ')' } axioms := { Axiom }VU, then the following is a functional-style syntaxontology document containing anof O SHOULD be accessible from the URI VU; furthermore, if O is the current version of the ontology series with the URI OU, then the ontology document of O SHOULD also be accessible from the URI <http://www.example.com/ontology1>OU.

This ontology importsThus, the document containing the current version of an ontology whoseseries with some URI OU SHOULD be accessible from OU. To access a particular version of OU, one needs to know that version's version URI VU; then, the ontology document SHOULD be accessedaccessible from <http://www.example.com/ontology2> , and itVU.

OWL 2 tools will often need to implement functionality such as caching or off-line processing, where ontology document MUST containdocuments may be stored at most one such definition per prefix,addresses different from the ones dictated by their ontology URIs and it MUST NOT containversion URIs. OWL 2 tools MAY implement a definition forredirection mechanism: when a prefix listed in Table 2. Prefix definitions aretool is used during parsingto expand CURIEs inaccess an ontology document at URI U, the tool MAY redirect U to a different URI DU and access the ontology document that is, partsfrom there instead. The result of accessing the ontology document matchingfrom DU MUST be the curie production into full URIssame as follows.if the prefix ofontology were accessed from U. Furthermore, once the CURIEontology document is not present, thenconverted into an ontology, the resulting full URI is equal toontology SHOULD satisfy the CURIE's reference. Ifthree conditions from the prefixbeginning of this section in the CURIE is present, then either Table 2 or the prefix definitions ofsame way as if it the ontology document being parsed MUST contain a definition associating the prefix with a namespace. The resulting full URI is obtained by concatenating the namespace name with the CURIE's reference. The full URI obtained bywere accessed from U. No particular redirection mechanism is specified — this expansion MUSTis assumed to be a valid URI. Ifimplementation dependent.

A version URI VU , then thefunctional-style syntax ontology document is a sequence of O SHOULD beUnicode characters [UNICODE] accessible from thesome URI VU ; furthermore, if O is the current versionby means of the ontology series withstandard protocols such that its text matches the URI OU , thenontologyDocument production of the grammar defined in this specification document, and it can be converted into an ontology documentby means of O SHOULD also be accessible fromthe URI OU . Thus, the document containing the current versioncanonical parsing process described in Section 3.6 and other parts of an ontology series with some URI OU SHOULD be accessible from OU . To accessthis specification document. A particular version of OU , one needs to know that version's version URI VU ; then, thefunctional-style syntax ontology document SHOULD be accessible from VU . An ontology document of anuse the UTF-8 encoding [RFC3629].

Each part of the ontology document at URI U ,matching the tool MAY redirect U toprefixDefinition production associates a different URI DUprefix with a namespace. An ontology document MUST contain at most one such definition per prefix and accessat most one such definition without a prefix, and it MUST NOT contain a definition for a prefix listed in Table 2. Prefix definitions are used during parsing to expand CURIEs in the ontology document from there instead. The result— that is, parts of accessingthe ontology document from DU MUST bematching the samecurie production — into full URIs as follows. The full URI obtained by this expansion MUST be a valid URI.

• If the ontology were accessed from U . Furthermore, onceprefix of the ontology documentCURIE is converted into an ontology,not present, then the ontology SHOULD satisfydocument being parsed MUST contain a definition without a prefix. The three conditions fromresulting full URI is obtained by concatenating the beginning of this section innamespace with the same way asCURIE's reference.
• If itthe ontology document were accessed from U . This specification does not specify any particular redirection mechanisms these are assumed to be implementation dependent. To enable off-line processing, an ontology document that according toprefix of the above rules should be accessible from <http://www.example.com/my> might be stored in a file accessible from <file:///usr/local/ontologies/example.owl> . To access this ontology document, an OWLCURIE is present, then either Table 2 tool might redirector the URI <http://www.example.com/my> and actually accessprefix definitions of the ontology document from <file:///usr/local/ontologies/example.owl> .being parsed MUST contain a definition associating the ontology obtained after accessing ontology document should satisfyprefix with a namespace. The usual accessibility constraints: ifresulting full URI is obtained by concatenating the ontology contains only the ontology URI, then the ontology URI should be equal to <http://www.example.com/my> , and if the ontology contains both the ontology URI andnamespace with the version URI, then one of them should be equal to <http://www.example.com/my> .CURIE's reference.

The conventions from Section 3.2.23.2 provide a simple mechanism for versioning OWL 2 ontologies. An ontology series is identified using an ontology URI, and each version in the series is assigned a different version URI. The ontology document of the ontology representing the current version of the series SHOULD be accessible from the ontology URI and, if present, at its version URI as well; the ontology documents of the previous versions SHOULD be accessible solely from their respective version URIs. When a new version O in the ontology series is created, the ontology document of O SHOULD replace the one acessible from the ontology URI (and it SHOULD also be accessible from its version URI).

From a physical point of view, an ontology contains a set of URIs, shown in Figure 1 as the directlyImportsDocuments association, that identify the ontology documents of the directly imported ontologies. These URIs SHOULD be interpreted as specified in Section 3.2.23.2 to access the ontology documents and convert them into ontologies; the result of this process determines the logical directly imports relation between ontologies, shown in Figure 1 as the directlyImports association. The logical imports relation between ontologies, shown in Figure 1 as the imports association, is the transitive closure of directly imports. In Figure 1, associations directlyImports and imports are shown as derived associations, since their values are derived from the value of the directlyImportsDocuments association; furthermore, ontology documents usually provide means to store the directlyImportsDocuments association, but not the directlyImports and imports associations.

The import closure of an ontology O is a set containing O and all allthe ontologies that O imports. The import closure of O SHOULD NOT contain ontologies O₁ and O₂ such that

• O₁ and O₂ are different ontology versions from the same ontology series, or
• O₁ contains an ontology annotation owl:incompatibleWith with the value equal to either the ontology URI or the version URI of O₂.

The axiom closure of an ontology O is the smallest set that contains all the axioms from each ontology O' in the import closure of O with all anonymous individuals renamed apart — that is, the anonymous individuals from different ontologies in the import closure of O are treated as being different; see Section 5.6.2 for further details.

An OWL 2 ontology contains a set of annotations. These can be used to associate information with an ontology such as— for example the ontology creator's name. As discussed in more detail in Section 10 in more detail,, each annotation consists of an annotation property and an annotation value, and the latter can be a literal, a URI, or an anonymous individual. Ontology annotations do not affect the logical meaning of the ontology.

OWL 2 provides several built-in annotation properties for ontology annotations. The usage of these annotation properties on entities other than ontologies is discouraged.

• The owl:priorVersion annotation property specifies the URI of a prior version of the containing ontology.
• The owl:backwardCompatibleWith annotation property specifies the URI of a prior version of the containing ontology that is compatible with the current version of the containing ontology.
• The owl:incompatibleWith annotation property specifies the URI of a prior version of the containing ontology that is incompatible with the current version of the containing ontology.

Many OWL 2 ontologies can contain values with built-in semantics, such as strings or integers. Such values are often called concrete , in ordertools need to distinguish them from the abstract values which are modeled using classes and individuals. Each kind of such values is called a datatype , andsupport ontology parsing — the setprocess of all supported datatypes is called a datatype map . A datatype map is notconverting an ontology document written in a syntactic construct that is includedparticular syntax into an OWL 2 ontologies; therefore, it is not includedontology. In order to be able to instantiate the appropriate classes from the structural specification of OWL 2. Each datatype in a datatype map is identified by a URI, and it can bespecification, the ontology parser sometimes needs to know which URIs are used in an OWL 2the ontology as described in Section 5.2 . More precisely, a datatype map is a 6-tuple D = ( N DT , N LS , N FS , DT , LS , FS ) with the following components. N DT is a set of datatypes, eachentities of which type. This typing information is identified by a URI, not containing the datatype rdfs:Literal . N LS is a functionextracted from declarations — axioms that assignsassociate URIs with entity types. Please refer to each datatype DT N DT a set N LS (DT) of strings called lexical values .Section 5.8 for more information about declarations.

In OWL 2 there is no requirement for each datatype DT N DT and each pair F V N FS (DT) , the interpretation function FS assigns to F V a facet value ( F V ) FS (DT) DT . To include a datatype DT intoa datatype map, one thus needsdeclaration of an entity to provide the lexical space N LS (DT) , the facet space N FS (DT) , the value space (DT) DT ,physically precede the data value ( LV DT ) LS for each LV N LS (DT) , and a facet value ( F V ) FSentity's usage in ontology documents; furthermore, declarations for each F V N FS (DT) . Such a specification is often identified with DTentities can be placed in imported ontology documents and is usually also called a datatype; the intended meaning of the term "datatype" is expectedimports are allowed to be clear from the context. The OWL 2 datatype map consists of datatypes describedcyclic. In order to precisely define the restresult of ontology parsing, this section, most of which are based on XML Schema Datatypes, version 1.1 [ XML Schema Datatypes ].specification defines the definitionsnotion of these datatypes incanonical parsing. An OWL 2 are largely the same as in XML Schema; however, there are minor differences, all of which are clearly identifiedparser MAY implement parsing in any way it chooses, as long as it produces a result that is structurally equivalent to the following sections. These differences were introduced mainly to align the semanticsresult of canonical parsing.

An OWL 2 datatypes with practical use cases. As shown in the OWL 2 Direct Semantics [ OWL 2 Direct Semantics ], the semantic consequences ofontology O_DGU corresponding to an ontology depend exclusively ondocument D_GU accessible at a given URI GU can be obtained using the setfollowing canonical parsing process. All steps of actually used datatypes. Implementations are therefore free to extendthis process MUST be successfully completed.

• The datatype map describedontology document D_GU is accessed from GU as specified in thisSection with extra datatypes without affecting3.4, and it is analyzed in order to extract the consequencesset of OWL 2 ontologies that do not use these datatypes. 4.1 Numbers OWL 2 provides a richURIs Imp(D_GU) of the directly imported ontology documents and the set of datatypes, listeddeclarations Decl(D_GU) explicitly present in Table 4,D_GU.
• The previous step is repeated recursively for representing various kinds of numbers. Value Spaces.each URI U from the value spaces ofset Imp(D_GU). Let AllDoc(GU) be the set containing D_GU as well as all numeric datatypes are shownontology documents (directly and indirectly) imported into D_GU.
• For each ontology document D in Table 4.AllDoc(GU), the value space of owl:realPlus containsfollowing steps are performed:
  • Let AllDecl(D) be the value spacesset of all other numeric datatypes. The special values -0declarations of D, +INFdefined as the union of the set Decl(D), -INFthe sets Decl(D') for each ontology document D' that is (directly or indirectly) imported into D, and NaN are not identical to any number.the set of declarations listed in particular, -0 is not a real number and it is not identical to real number zero; to stress this distinction, the real number zero is often called a positive zero , written +0 .Table 4. Numeric Datatypes and Their Value Spaces Datatype Value Space owl:realPlus9. The set of all real numbers extended with four special values -0 ( negative zero ), +INF ( positive infinity ), -INF ( negative infinity ), and NaN ( not-a-number ) owl:realAllDecl(D) MUST satisfy the settyping constraints from Section 5.8.1.
  • An instance O_D of all real numbers owl:rationalthe set of all rational numbers xsd:doubleOntology class from the four special values -0 , +INF , -INF ,structural specification is created. The document D is then analyzed again and NaN , plusO_D is populated by instantiating appropriate classes from the set of all real numbersstructural specification according to the rules of the form m 2 e where m is an integer whose absolute value is less than 2 53respective syntax. Declarations in AllDecl(D) are used to disambiguate URI references, and eit MUST be possible to disambiguate all URI references. If D is an integer between -1075 and 970, inclusive xsd:floata functional-style syntax ontology document, then the four special values -0declarations in AllDecl(D) are used to disambiguate the productions for Class, +INFDatatype, -INFObjectProperty, and NaNDataProperty, plus the set of all real numbersAnnotationProperty, and NamedIndividual.
• For each pair of ontology documents D₁ and D₂ in AllDoc(GU) such that the form mlatter is directly imported into the former, O_D2 e where mis an integer whose absolute value is less than 2 24 and e is an integer between -149 and 104, inclusive xsd:decimaladded to the set of all real numbersdirectlyImports association of O_D1.
• The form i 10 -n where istructure of O_D is an integerchecked for each ontology document D in AllDoc(GU), and nO_D MUST be an OWL 2 ontology — that is, it must satisfy all the restrictions listed in Section 3.

It is a nonnegative integer xsd:integerimportant to understand that canonical parsing merely defines the setresult of all integers xsd:nonNegativeIntegerthe setparsing process, and that a "smart" implementation of OWL 2 MAY optimize this process in numerous ways. In order to enable efficient parsing, OWL 2 implementations are encouraged to write ontologies into documents by placing all nonnegative integers xsd:nonPositiveIntegerURI declarations before the set of all negative integers plus (positive) zero xsd:positiveIntegeraxioms that use these URIs; however, this is not required for conformance.

OWL 2 ontologies can contain values with built-in semantics, such as strings or integers. Such values are often called concrete, in order to distinguish them from the abstract values which are modeled using classes and individuals. Each kind of all integers between 0such values is called a datatype, and 65535, inclusive xsd:unsignedBytethe set of all integers between 0 and 255, inclusive Feature At Risk #1: owl:rational support Note: This featuresupported datatypes is "at risk" and may be removed from this specification based on feedback. Please send feedback to public-owl-comments@w3.orgcalled a datatype map. The owl:rationalA datatype might be removed frommap is not a syntactic construct that is included in OWL 2 if implementation experience reveals problems with supporting this datatype. Lexical Sapce. Datatypes owl:realPlus and owl:real do not directly provide any lexical values. The owl:rational datatype supports lexical values defined by the following grammar (whitespace within the grammar MUST be ignored and MUSTontologies; therefore, it is not beincluded in the lexical valuesstructural specification of owl:dateTimte ,OWL 2. Each datatype in a datatype map is identified by a URI, and single quotes areit can be used to introduce terminal symbols): numerator '/' denominator where numerator isin an integer with the syntaxOWL 2 ontology as specified for the xsd:integer datatype, and denominatordescribed in Section 5.2.

More precisely, a datatype map is a positive, nonzero integer6-tuple D = ( N_DT , N_LS , N_FS , ⋅ ^DT , ⋅ ^LS , ⋅ ^FS ) with the syntax as specified for the xsd:integer datatype, not containing the plus sign.following components.

• N_DT is a set of datatypes, each such lexical valueof owl:rationalwhich is mapped to the rational number obtainedidentified by dividing numerator with denominatora URI, not containing the datatype rdfs:Literal.
• For DTN_LS is a function that assigns to each datatype from XML schema, lexical values ofDT are defined as specified in XML Schema Datatypes [ XML Schema Datatypes ]. Furthermore, each pair "abc"∈ N_DT is assigneda data value by interpreting "abc" as specified in XML Schema Datatypes [ XML Schema Datatypes ] for DT . Theset N_LS(DT) of strings called lexical values of owl:rational , xsd:decimal , and. The datatypes derived from xsd:integer are mapped to arbitrarily large and arbitrarily precise numbers. An OWL 2 implementation MAY support all such lexical values; however, it MUST support at leastset N_LS(DT) is called the following corelexical values, which can be easily mappedspace of DT.
• N_FS is a function that assigns to the primitive values commonly found in modern implementation platforms: All xsd:float and xsd:double lexical values are core lexical values.each datatype DT ∈ N_DT a lexical valueset N_FS(DT) of type owl:rationalpairs of the form ⟨ F V ⟩, where F is a core lexical value if its numeratorconstraining facet and denominator are in the value space of xsd:long . A lexical value of type xsd:decimalis identified by a core lexical value if its data valueURI, and V is an arbitrary object called a number with absolutevalue less than 10 16 and the representation of. The number requires at most 16 digits in total.set N_FS(DT) is called the facet space of DT.
• For each datatype DT ∈ N_DT, the interpretation function ⋅ ^DT assigns to DT a set (DT)^DT called the value space of DT.
• For each datatype DT ∈ N_DT and each lexical value LV ∈ N_LS(DT), the interpretation function ⋅ ^LS assigns to the pair ⟨ LV DT ⟩ a data value (⟨ LV DT ⟩)^LS ∈ (DT)^DT.
• For xsd:integer oreach datatype DT ∈ N_DT and each pair ⟨ F V ⟩ ∈ N_FS(DT), the interpretation function ⋅ ^FS assigns to ⟨ F V ⟩ a type derived from xsd:integer isfacet value (⟨ F V ⟩)^FS ⊆ (DT)^DT.

To include a coredatatype DT into a datatype map, one thus needs to provide the lexical space N_LS(DT), the facet space N_FS(DT), the value if itsspace (DT)^DT, the data value is in the(⟨ LV DT ⟩)^LS for each LV ∈ N_LS(DT), and a facet value space of xsd:long(⟨ F V ⟩)^FS for each ⟨ F V ⟩ ∈ N_FS(DT). Feature At Risk #2: xsd:decimal precision Note: This featureSuch a specification is "at risk"often identified with DT and mayis usually also called a datatype; the intended meaning of the term "datatype" is expected to be removedclear from the context.

The OWL 2 datatype map consists of datatypes described in the rest of this specificationsection, most of which are based on feedback. Please send feedback to public-owl-comments@w3.org . The newXML Schema spec contains an acknowledged editorial error inDatatypes, version 1.1 [XML Schema Datatypes]. The definitiondefinitions of core lexical values for xsd:decimal . This document will be updated to state that core decimal lexical valuesthese datatypes in OWL 2 are those that can be expressed with sixteen decimal digits, as is stated here. This document will be updated to uselargely the wordingsame as in theXML Schema spec if the changeSchema; however, there is madeare minor differences, all of which are clearly identified in time. Equality and Ordering.the facet space offollowing sections. These differences were introduced mainly to align the numericsemantics of OWL 2 datatypes are basedwith practical use cases.

As shown in the OWL 2 Direct Semantics [OWL 2 Direct Semantics], the semantic consequences of an ontology depend exclusively on the following definitionsset of equality and ordering.actually used datatypes. Implementations are therefore free to extend the equality = isdatatype map described in this section with extra datatypes without affecting the smallest symmetric relation onconsequences of OWL 2 ontologies that do not use these datatypes.

Lexical Spaces. Datatypes ]. 4.2 Strings OWL 2 usesowl:realPlus and owl:real do not directly provide any lexical values.

The rdf:textowl:rational datatype forsupports lexical values defined by the representation of stringsfollowing grammar (whitespace within the grammar MUST be ignored and MUST NOT be included in a particular language.the definitionslexical values of owl:dateTime, and single quotes are used to introduce terminal symbols):

where numerator is an integer with the value space, the lexical space,syntax as specified for the facet space,xsd:integer datatype, and denominator is a positive, nonzero integer with the necessary mappingssyntax as specified for the xsd:integer datatype, not containing the plus sign. Each such lexical value of owl:rational is mapped to the rational number obtained by dividing numerator by denominator.

For DT a datatype from XML schema, lexical values of DT are given in [ RDF:TEXT ].defined as specified in addition, OWL 2 supports the followingXML Schema Datatypes [XML Schema Datatypes ]: xsd:string xsd:normalizedString xsd:token xsd:language xsd:Name xsd:NCName xsd:NMTOKEN]. Furthermore, each pair ⟨ "abc" DT ⟩ is assigned a data value by interpreting "abc" as recommendedspecified in XML Schema Datatypes [ RDF:TEXT ],XML Schema Datatypes] for DT.

The value spaceslexical values of theseowl:rational, xsd:decimal, and the datatypes derived from xsd:integer are subsets of the value space of rdf:text ; please refermapped to [ RDF:TEXT ] for aarbitrarily large and arbitrarily precise definition. 4.3 Boolean Valuesnumbers. An OWL 2 implementation MAY support all such lexical values; however, it MUST support at least the xsd:boolean datatype allows forfollowing core lexical values, which can easily be mapped to the representation of Booleanprimitive values commonly found in modern implementation platforms:

• All xsd:float and xsd:double lexical values are core lexical values.
• A lexical value Space. The value spaceof xsd:booleantype owl:rational is the set containing exactly the two values truea core lexical value if its numerator and false . These valuesdenominator are not containedin the value space of any other datatype.xsd:long.
• A lexical Space. The xsd:boolean datatype supports the followingvalue of type xsd:decimal is a core lexical values: "true" and "1" are mapped to the datavalue true , and "false" and "0" are mapped to theif its data value false . Facet Space. The xsd:boolean datatype does not support any constraining facets. 4.4 Binary Data Datatypes xsd:hexBinaryis a number with absolute value less than 10¹⁶ and xsd:base64Binary allow forthe representation of binary data. The two datatypes arethe same apart from fact that they supportnumber requires at most 16 digits in total.
• A different syntactic representationlexical value for xsd:integer or a type derived from xsd:integer is a core lexical values.value Spaces.if its data value is in the value space of both xsd:hexBinary and xsd:base64Binaryxsd:long.