rdfs:Literal is an instance of rdfs:Class that is the class of literal values such as strings and integers.  rdfs:Literal is a subclass of rdfs:Resource.

EXAMPLE:    Property values such as textual strings are examples of rdfs:Literal.


    <rdfs:Class rdf:about="http://www.w3.org/2000/01/rdf-schema#Literal">

        <rdfs:isDefinedBy rdf:resource="http://www.w3.org/2000/01/rdf-schema#"/>


        <rdfs:comment>The class of literal values, eg. textual strings and integers.</rdfs:comment>

        <rdfs:subClassOf rdf:resource="http://www.w3.org/2000/01/rdf-schema#Resource"/>


Example listing



ex:index.html  exterms:creation-date  "August 16, 1999"  states that the web page ex:index.html has been created on August 16, 1999.


ex:index.html   exterms:creation-date   "1999-08-16"^^xsd:date  also states that the web page ex:index.html has been created on August 16, 1999, but this time easier recognizable by the software as date.


No explicit example of the use of rdfs:Literal found.


    <rdf:Description rdf:about="http://www.example.org/index.html"> 

        <exterms:creation-date>August 16, 1999</exterms:creation-date>  



    <rdf:Description rdf:about="http://www.example.org/index.html"> 

        <exterms:creation-date  rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1999-08-16 </exterms:creation-date>


Other information

Literals are used to identify values such as numbers and dates by means of a lexical representation. Anything represented by a literal could also be represented by a URI, but it is often more convenient or intuitive to use literals.

A literal may be the object of an RDF statement, but not the subject or the predicate.

Literals may be plain or typed :

The string in both plain and typed literals is recommended to be in Unicode Normal Form C [NFC].

RDF provides for the use of externally defined datatypes identified by a particular URI reference. In the interests of generality, RDF imposes minimal conditions on a datatype. It also includes a single built-in datatype rdf:XMLLiteral.

This semantics for datatypes is minimal. It makes no provision for associating a datatype with a property so that it applies to all values of the property, and does not provide any way of explicitly asserting that a blank node denotes a particular datatype value. Semantic extensions and future versions of RDF may impose more elaborate datatyping conditions. Semantic extensions may also refer to other kinds of information about a datatype, such as orderings of the value space.

A datatype is an entity characterized by a set of character strings called lexical forms and a mapping from that set to a set of values. Exactly how these sets and mappings are defined is a matter external to RDF.

Formally, a datatype d is defined by three items:

1. a non-empty set of character strings called the lexical space of d;

2. a non-empty set called the value space of d;

3. a mapping from the lexical space of d to the value space of d, called the lexical-to-value mapping of d.

The lexical-to-value mapping of a datatype d is written as L2V(d).

In stating the semantics we assume that interpretations are relativized to a particular set of datatypes each of which is identified by a URI reference.

Formally, let D be a set of pairs consisting of a URI reference and a datatype such that no URI reference appears twice in the set, so that D can be regarded as a function from a set of URI references to a set of datatypes: call this a datatype map. (The particular URI references must be mentioned explicitly in order to ensure that interpretations conform to any naming conventions imposed by the external authority responsible for defining the datatypes.) Every datatype map is understood to contain <rdfs:Literal, x> where x is the built-in XML Literal datatype whose lexical and value spaces and lexical-to-value mapping are defined in the RDF Concepts and Abstract Syntax document [RDF-CONCEPTS].

The datatype map which also contains the set of all pairs of the form <http://www.w3.org/2001/XMLSchema#sss, sss>, where sss is a built-in datatype named sss in XML Schema Part 2: Datatypes [XML-SCHEMA2] and listed in the following table, is referred to here as XSD.

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

The other built-in XML Schema datatypes are unsuitable for various reasons, and SHOULD NOT be used: xsd:duration does not have a well-defined value space (this may be corrected in later revisions of XML Schema datatypes, in which case the revised datatype would be suitable for use in RDF datatyping); xsd:QName and xsd:ENTITY require an enclosing XML document context; xsd:ID and xsd:IDREF are for cross references within an XML document; xsd:NOTATION is not intended for direct use; xsd:IDREFS, xsd:ENTITIES and xsd:NMTOKENS are sequence-valued datatypes which do not fit the RDF datatype model.

Use in ISO 15926