Datatypes

The RDF semantics recommendation identifies a subset of XML schema datatypes that are suitable for use in RDF. The following XML datatypes may be used in RDF typed literals. For example, an xs:string "foobar", would be represented in RDF (N3) as "foobar"^^<http://www.w3.org/2001/XMLSchema#string>.

• xs:string
• xs:boolean
• xs:decimal
• xs:float
• xs:double
• xs:dateTime
• xs:time
• xs:date
• xs:gYearMonth
• xs:gYear
• xs:gMonthDay
• xs:gDay
• xs:gMonth
• xs:hexBinary
• xs:base64Binary
• xs:anyURI
• xs:normalizedString
• xs:token
• xs:language
• xs:NMTOKEN
• xs:Name
• xs:NCName
• xs:integer
• xs:nonPositiveInteger
• xs:negativeInteger
• xs:long
• xs:int
• xs:short
• xs:byte
• xs:nonNegativeInteger
• xs:unsignedLong
• xs:unsignedInt
• xs:unsignedShort
• xs:unsignedByte
• xs:positiveInteger

datatype example

The exceptions include:

• xs:anySimpleType
• xs:duration
• xs:ENTITY
• xs:ENTITIES
• xs:ID
• xs:IDREF
• xs:IDREFS
• xs:NMTOKENS
• xs:NOTATION
• xs:QName

See also:

http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ http://www.w3.org/TR/xpath-functions/ http://www.w3.org/TR/swbp-xsch-datatypes/

The following sections explore work-arounds for all of these datatypes.

The mother of all simple types (xs:anySimpleType)

This type is the base of all simple types with an unconstrained lexical space. User defined restrictions of xs:anySimpleType are not allowed. Indeed, users are generally advised to steer clear of it altogether.

Yet, both elements and attributes may be defined to be of type xs:anySimpleType (it's also the default type for attributes). Also, anySimpleType may be used as the base of a simpleContent extension.

Thinking about an RDF savvy mapping, it occupies a similar place in the pantheon of classes as rdfs:Literal, the superclass of all literals including datatypes. Thus any XML content of type xs:anySimpleType is mapped to an rdfs:Literal.

anySimpleType example

See also:

http://www.w3.org/2001/05/xmlschema-rec-comments#pfiS4SanySimpleType http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2002Jan/0065.html

Duration (xs:duration)

The problem with xs:duration is that there's no well-defined total ordering over it's value space (durations are partially ordered). The problem stems from there being an indeterminate number of days in a month. The recommended solution used by Gloze is to distill a single period such as "P7Y2M26DT14H18M10S" (years, months, days, hours, minutes, seconds) into separate xs:yearMonthDuration "P7Y2M" (years, months) and xs:dayTimeDuration "P26DT14H18M10S" (days, hours, minutes, seconds) datatypes. The reverse process, is equivalent to adding the these values, both of which are subclasses of duration. When adding two durations, each component is added independently, ignoring - in particular - any carry from days to months.

duration example

Entities (xs:ENTITY)

An XML schema ENTITY allows the substitution of common text values or balanced mark-up defined as XML entities. ENTITY values must match an entity name declared in the DTD of the instance document. The value space of unexpanded entities is scoped to the instance document it appears in. For the XML to RDF mapping, internally defined entities are therefore expanded. As they may include balanced mark-up, an expanded entity can be described as an RDF XMLLiteral. There is currently no reverse mapping due to technical issues in editing document type declarations in level 2 DOM.

entity example

See also:

http://jena.sourceforge.net/how-to/typedLiterals.html#xsd

Identity datatypes (xs:ID, xs:IDREF)

An element is considered to have an ID if it has an attribute of type ID, or if the type of the element itself is an ID.

IDs have no distinguishing features looking at the XML alone, they look like ordinary content. We look to the XML schema which will identify the datatype as xml schema ID. The ID is associated with the enclosing element, and that element can have at most one ID.

XML IDs are defined to have document scope, such that a given ID must be unique within a single document and that each ID reference should have a corresponding ID within the same document. One advantage of the mapping into RDF is that a single RDF model may contain descriptions of multiple documents. We have ensure that we preserve the global uniqueness of identifiers, and do not lose the correlation between IDs and their references when moving to this global context. An identifier of type ID can be transformed into a URI by treating it as a fragment identifier relative to the document base.

For example, a base http://example.org/base an XML ID "foobar" combine to give the URI, http://example.org/base#foobar .

Properties of type ID will disappear, as these simply define the URI of the identified resource. A corresponding reference to this resource with an IDREF is similarly expanded into a URI reference.

identity example

Notation (xs:NOTATION)

NOTATIONs are restricted to QNames declared in the schema. For the purposes of RDF mapping they are subject to the same rules as QNames. The target namespace and notation name are expanded to give an absolute URI for the notation resource.

notation example

Qualified Names (xs:QName)

QNames define the space of (optionally) qualified local names. The scope of an XML namespace prefix includes the element it is defined in and its children (subject to shadowing). This lexical scoping doesn't translate directly into RDF where everything has global scope. However, the expanded QName is a URI, so it may be translated into an object reference, though typically we have no knowledge of the type of object referred to. This URI becomes associated with a resource.

For example, given a namespace prefix 'eg' defined as "http://example.org" the QName "eg:foobar" would be expanded to give the URI, http://example.org#foobar .

QName example

List types (xs:IDREFS, xs:ENTITIES, xs:NMTOKENS)

Although list types are treated as simple in XML schema, they are not recommended for use in RDF. Instead, we construct an rdf:list of the corresponding non-list type (xs:IDREF, xs:ENTITY, xs:NMTOKEN).

IDREFS example

---