The RDF/XML Serialization RDF statements can be written in RDF/XML very much like descriptions in non-RDF XML XML is increasingly used in all kinds of applications  RDF could be used in these applications without major changes in how their info is structured But RDF/XML requires special software  Don’t use DOM or SAX  Use, e.g., Jena

Consider the triple exterms:creation-date "August 16, 1999". In exterms:. exterms:creation-date "August 16, 1999".  (Can’t define a prefix ex: and use ex:index.html as the subject—the file extension is prohibited)

In RDF/XML <rdf:RDF xmlns:rdf=" xmlns:exterms=" August 16, 1999 The 1 st line is the XML declaration: indicates that the following content is XML and giving the XML version The rest of the document is an rdf:RDF element The opening rdf:RDF tag declares 2 namespace prefixes  General form xmlns:ns = URI where ns is the namespace prefix being defined, and URI (a string) is the corresponding URI

 Also a form xmlns= URI that defines the default namespace for the document  Any unqualified element or attribute name is in this namespace  Don’t use default namespaces here The rdf:RDF itself is a QName whose prefix is defined in its opening tag The 2 prefix definitions here are equivalent to the N3 exterms:. Note that all elements and attributes but 1 in this document are in the rdf: namespace  The exception is the element exterms:creation-date

The content of the rdf:RDF element is the single element August 16, 1999  The value of the rdf:about attribute of the rdf:Description element is the triple’s subject  The element that is the sole content of the rdf:Description element is the predicate  The content of this latter element is the object in the triple This is how triples are represented in the most basic way in RDF/XML More generally  URIrefs of object nodes may sometimes be written as attribute values (see below)  Literal nodes are always object nodes

W3C’s RDF Validator Paste your RDF/XML into the text area  Alternatively, provide the URI whence your RDF/XML document can be uploaded From the menu, select Triples Only, Graph Only, or Triples and Graph Can also select the graph format  The default (PNG – embedded) is fine Click Parse XML Displays errors & warnings (if appropriate), identified by line & column  Tries to find some interpretation even in the presence of fatal errors Shows the original document (depending on your choice), the triples, and graph

Triples and graph for the current example

Represent an RDF-graph with multiple triples by including multiple rdf:Description elements in the content of the rdf:RDF element E.g., add another triple (and another prefix) to the last example so it corresponds to the dc:. exterms:creation-date "August 16, 1999". dc:lang "en". Any number of statements could be added in this way, using a separate rdf:Description element for each

The RDF/XML: <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" August 16, 1999 en New

The RDF graph from the Validator

The RDF/XML syntax provides several abbreviations E.g., when the same subject (resource) is described with several properties and values (objects), we can represent these property-object pairs inside the rdf:Description element identifying the subject E.g., consider the following N3 document—RDF graph on the next dc:. exterms:creation-date "August 16, 1999". dc:language "en". dc:creator exstaff:85740.

The corresponding RDF/XML <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" August 16, 1999 en New feature

A new feature in the line The value of the dc:creator property is another resource (not a literal)  If the URIref of this resource were written as a literal within start and end tags, it would say that the value of the dc:creator property is the character string “ ”  But we want the resource identified by the literal interpreted as a URIref So the dc:creator element is written as an XML empty-element tag:  No separate end tag, and a “ / ” before “ > ”  The property value is written as the value of this element’s rdf:resource attribute

In general, the rdf:resource attribute indicates that the property element's value is another resource, identified by its URIref Since the URIref is used as an attribute value, XML requires the URIref to be written out as an absolute or relative URIref  Can’t be abbreviated as a QName (as with element and attribute names)

Property Attributes When a property element's content is a literal, we can capture it instead as an attribute on the containing rdf:Description element provided the property element name isn’t repeated  XML attribute names must be unique It’s then a property attribute Can do this also when the property element is rdf:type and it has an rdf:resource attribute whose value is a URIref

In the previous example, the property elements whose contents are literals are dc:language and exterms:creation-date  Turning these into a property attributes gives <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" <rdf:Description rdf:about=" dc:language="en" exterms:creation-date="August 16, 1999">

Blank Nodes (Bnodes) Consider the English statement “The document has a title ‘RDF/XML Syntax Specification (Revised)’ and has an editor, whose name is ‘Dave Beckett’, and a home page In exterms:. dc:title "RDF/XML Syntax Specification (Revised)"; exterms:editor [ exterms:fullName "Dave Beckett"; exterms:homepage ]. See the RDF graph on the next page

In N-Triples (closer to the RDF/XML representation), using the same prefixes dc:title "RDF/XML Syntax Specification (Revised)". exterms:editor _:bnode0. _:bnode0 exterms: fullName "Dave Beckett". _:bnode0 exterms: homepage.

The most direct way to representing bnodes in RDF/XML is to assign a blank node (or bnode) identifier to each blank node in the document  Not a URIref—you make up a (short) name A statement with a bnode as subject is written using an rdf:Description element that has an rdf:nodeID (instead rdf:about ) attribute with the bnode identifier as its value A statement with a bnode as object is written using a property element that has an rdf:nodeID (instead of rdf:resource ) attribute

So the corresponding RDF is <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" RDF/XML Syntax Specification (Revised) Dave Beckett

A bnode can be written so that the tags are omitted from its representation  It’s absorbed into the rdf:Description element where it’s referenced as object Do the following  Take the (empty) property element (here exterms:editor ) that has the bnode as object  Put an rdf:parseType="Resource" attribute on it and remove its rdf:nodeID attribute  Put the property elements describing the bnode’s properties as its content  Eliminate the rdf:Description element for the bnode subject

The following is the result of this transformation applied to the previous example  Also make dc:title a property attribute <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:exterms=" <rdf:Description rdf:about=" dc:title="RDF/XML Syntax Specification (Revised)"> Dave Beckett

Further abbreviation is possible If  all property elements on a blank node element have string values,  each of these property elements appears at most once, and  there’s at most 1 rdf:type property element with a URIref object node, then these property elements can be moved to be property attributes on the containing property element (introduced when the rdf:Description element for the bnode was eliminated)  Then remove the rdf:parseType attribute from the containing property element and make it empty

In the last example, the ex:editor property element contains a bnode element with 2 property elements ex:fullname and ex:homepage  ex:homePage doesn’t have a literal value  So ignore it here, and consider the following document <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:ex=" <rdf:Description rdf:about=" dc:title="RDF/XML Syntax Specification (Revised)"> Dave Beckett

Now remove the ex:fullName property element  Add to the exterms:editor property element a new property attribute exterms:fullName with the literal value of the deleted property element <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:ex=" <rdf:Description rdf:about=" dc:title="RDF/XML Syntax Specification (Revised)"> It’s easy to read this as “The document has a title ‘RDF/XML Syntax Specification (Revised)’ and has an editor, whose name is ‘Dave Beckett’.”

Typed Literals Typed literals may be used as property values A typed literal is represented by adding to the property element containing the literal an rdf:datatype attribute whose value is the datatype URIref  The datatype is usually an XML Schema datatype, in the namespace corresponding conventionally to the prefix xsd But recall that an XML attribute value can’t be written as a QName but must be written with the full URIref  If an XML Schema datatype value is used, the literal must conform to its syntax

E.g., consider again the RDF/XML document <rdf:RDF xmlns:rdf=" xmlns:exterms=" August 16, 1999

The following changes untyped literal August 16, 1999 to something equivalent to the N3 typed literal " "^^xsd:date <rdf:RDF xmlns:rdf=" xmlns:exterms=" <exterms:creation-date rdf:datatype= "

XML Entities to Abbreviate URIrefs in Attribute Values XML prohibits QNames to be used as attribute values  In the last example, had to write out the entire URIref for the value for the rdf:datatype value rdf:datatype=" To avoid long URIrefs in descriptions, can use another abbreviation facility (besides QNames) provided by XML: entities The following is a long digression on XML entities  Needed to put this technique in context

Document Type Declaration Just after the XML declaration, an XML document optionally contains a document type declaration of the form <!DOCTYPE root-element DTD location [ internal subset ]> The root element name is the only part required  This is the name of the root element in the document  In an RDF/XML document, always rdf:RDF

The DTD location gives the location (e.g., URL) of the DTD (Document Type Definition) against which the current document is validate  An RDF/XML document is never validated against a DTD (or anything else, like an XML Schema), so we always omit this The internal subset is the only place within the document itself where we can put declarations used in the document  It augments the declarations in the external subset, the collection of declarations in the DTD As we use no DTD, we never have an external subset  The only declarations in the internal subset for an RDF/XML document are entity declarations

Entities An entity is a placeholder for content  Declare it once, use it many times (like macro substitution) almost anywhere in the document Parameter entities are used only in DTDs: not of interest here General entities (used in XML documents) are placeholders for any content at the level of or inside the root element of a document A general entity reference has the form &name; where name is the entity name

An entity consists of a name and a value When an XML parser (e.g., the parser for the RDF Validator or for the Jena Semantic Web framework) processes a document, it first reads a series of declarations  Some (for us, all) of these declarations define entities by associating a name with a value  When the parser later encounters an entity reference, it consults a table for the text with which to replace it  An entity reference inside the replacement is replaced recursively

A document that declares 3 entities and references them <!DOCTYPE message [ "> ]> Dear &client; To reserve a place for your holiday in Piñata, Mexico, call &agent; at &phone; Entities client, agent, and phone are mixed-content entities  Declared in the internal subset, referenced in the message element Entity #241 is a numbered character entity representing ñ  Referenced but not declared  Numbered character entities are implicitly defined in XML

The following shows how this is displayed by Firefox  All entity references are resolved

Kinds of general entities general entities character predefined numberednamed mixed-content unparsed internalexternal An unparsed entity contains something other than text (e.g., name of an image file)  Shouldn’t be parsed

Character entities (each denoting 1 character) are predefined, numbered, or named  Predefined character entities are for characters that conflict with the special markup delimiters amp ( & ), apos ( ′ ), gt ( > ), lt ( < ), quote ( " )  To enter a nonstandard character from the keyboard, use a numbered character entity of the form #n, where n is a number representing the character’s position in the Unicode character set The number may be in decimal or (preceded by an x ) hex E.g., ç is represented as #231 (decimal) or #xe7 (hex)  Named character entities are mnemonic names Must be declared But large groups are defined in special DTD modules

Mixed-content entities have values of unlimited length  Can include markup as well as text  For internal entities, the replacement text is defined in the entity declaration  For external entities, it’s located in another file  We use only internal mixed-content entities

Return to: Entities and RDF/XML In the previous RDF/XML example, wanted to define an entity whose name is xsd and whose value is the string " This is all that’s in the internal subset, which, besides the root element’s name ( rdf:RDF ), is all that’s in the document type declaration: ]>  Note the “#” Can now replace the URIref " that’s the value of the rdf:datatype attribute of the exterms:creation-date property element with the abbreviated form "&xsd;date"  Note the quotation marks

The entire document ]> <rdf:RDF xmlns:rdf=" xmlns:exterms="

Recap Can generally avoid using URIrefs in descriptions (except for the subject resource—cf. the rdf:about attribute)  In all places except attribute values, use QNames Prefix defined using the “ xmlns ” notation in the opening rdf:RDF tag  In attribute values, use an (internal mixed-content) entity Defined in the document type declaration

Abbreviating and Organizing RDF URIrefs So far, the examples have a full URIref for each resource being described  E.g., resource was identified using an rdf:about attribute citing its full URIref RDF doesn’t specify or control how URIrefs are assigned to resources  This involves “resolving” URIs: relating domain names to the IP protocol, path names to the local file system, and fragment identifiers to the software handling the document

 See the RFC 3986 (2005) specification by the Network Working Group of the Internet Society  Other specifications of the IETF (Internet Engineering Task Force) and W3C But sometimes we want to achieve the effect of  assigning a URIref (specifically, a URI and a fragment identifier)  to a resource (identified by the fragment identifier) that’s part of an organized group of resources (identified by the URI alone) First review fragment identifiers in HTML (where they have a visual effect)

Fragment Identifiers in HTML Consider the following HTML document Illustrating Fragment Identifiers Frying an Egg Step 1 Step 2 Step 3 Step 1 Break the egg in the heated frying pan. Continued

Step 2 Leave the egg in the pan until it's done Step 3 Take the egg out of the pan. The a elements before the h5 elements define names—fragment identifiers—associate with the locations in the document where they occur (just before the h5 elements)

Each a element in the list (near the top of the document) has an href attribute  Its value is one of the 3 fragment identifiers preceded by a # The rendering showing just the top of the document (the list) is below at left  If we click, say, Step 1, the browser scrolls to the location associated with fragment identifier step1  See the screenshot on the right

This use of fragment identifiers actually uses a relative URIref  The URI part is exactly the URI of the document  So all we need specify is the fragment identifier Suppose the URI of the document is  If you put exactly that in the address bar of your browser, you’ll see the document from the top down to where the browser window ends (see the screenshot above at left)  If you put in the address bar you’ll see something like the screenshot above at right

URIrefs similarly take you to the corresponding parts of the document The important point is a fragment identifier identifies a part of a document (hence the name) Fragment identifiers also occur with XML (and RDF/XML) documents

Back to “Abbreviating and Organizing RDF URIrefs” Now consider how we might exploit fragment identifiers in RDF/XML Suppose sporting goods company example.com wants an RDF-based catalog of its products as an RDF/XML document, identified by (and located at)  In that resource, each product has a separate RDF description associated with a unique fragment identifier  The following shows the catalog with all but one of the product descriptions removed

]> <rdf:RDF xmlns:rdf=" xmlns:exterms=" Overnighter other product descriptions... We’ve given datatypes with the property values but not units  Representing units and other info associated with property values is covered later New feature here: the rdf:Description element has an rdf:ID attribute instead of an rdf:about attribute

rdf:ID specifies a fragment identifier ( item10245 here, perhaps a catalog number) The value of the rdf:ID attribute is an abbreviation of the complete URIref of the resource  It’s interpreted relative to a base URI, here the URI of the containing catalog document  Gives the absolute URIref

The rdf:ID attribute is like the id attribute in XML and HTML  It defines a name that’s unique relative to the current base URI (that of the catalog here) The rdf:ID attribute appears to be assigning a name ( item10245 ) to this kind of tent Another RDF/XML element in this catalog can refer to the tent by using  either the absolute URIref  or the relative URIref #item10245 understood as a URIref defined relative to the base URIref of the catalog

The URIref of the tent could also be given by specifying rdf:about="#item10245" in the catalog entry—specifying the relative URIref directly— instead of rdf:ID="item10245" As an abbreviation mechanism, the 2 forms are synonyms: the full URIref is the same in either case But rdf:ID provides an additional check: A given rdf:ID value must be unique relative to the same base URI (the catalog document, in this example)

RDF outside the catalog can refer to this tent with the full URIref: Concatenate the relative URIref #item10245 to the base URI of the catalog, giving the absolute URIref E.g., exampleRatings.com might use RDF to provide ratings of various tents  The rating given to our tent could be represented as on the next slide

]> <rdf:RDF xmlns:rdf=" xmlns:sportex=" <rdf:Description rdf:about=" Richard Roe 5 The value of the rdf:about attribute in the rdf:Description element is the full URIref of the tent

Even though RDF doesn’t control how URIrefs are assigned to resources, the effect of assigning URIrefs to resources in RDF can be achieved by combining  a process (external to RDF) that identifies a single document (here the catalog) as the source for descriptions of those resources with  the use of relative URIrefs in descriptions of those resources within that document E.g., example.com could use this catalog as the central source where its products are described  It’s understood that, if a product's item number isn’t in an entry in the catalog, it isn’t a product known to example.com  But RDF doesn’t assume 2 resources are related just because their URIrefs have the same base

A basic architectural principle of the Web: Anyone can freely add info about an existing resource, using any vocabulary they please The RDF describing a particular resource may be distributed throughout the Web  E.g., in the above example, one document comments on a resource defined by another  Also happens if the original definer of a resource (or anyone else) amplifies the resource’s description with additional info Can be done in a separate document that provides the additional properties and values in rdf:Description elements that refer to the original resource via its URIref using rdf:about

Base URI Recall that relative URIrefs (e.g., #item10245 ) are interpreted relative to a base URI  By default, the base URI is the URI of the resource where the relative URIref is used But we can explicitly specify this base URI E.g., suppose that, besides the catalog located at example.org provides a duplicate catalog on mirror site

But, if the catalog is accessed from the mirror site, the URIref for the tent is generated from the URI of the containing document, forming not  So it refers to a different resource than intended RDF/XML supports XML Base  Lets an XML document specify a base URI other than the URI of the document itself The next slide shows how the catalog would be described using XML Base

]> <rdf:RDF xmlns:rdf=" xmlns:exterms=" xml:base=" Overnighter other product descriptions...

Here the xml:base declaration specifies that the base URI for the content within the rdf:RDF element (until another xml:base attribute is specified) is All relative URIrefs cited within that content are interpreted relative to that base  So the relative URIref of the tent, #item10245, is interpreted as the same absolute URIref This is so  no matter what the actual URI of the catalog document is or  whether the base URIref actually identifies a particular document

Typed Nodes RDF supports the concept of a category to which things belong by providing predefined property rdf:type When an RDF resource is described with an rdf:type property,  the value of that property is a resource that represents a category or class of things, and  the subject of that property is an instance of that class The next slide shows how to use rdf:type to indicate that the product description is that of a tent

]> <rdf:RDF xmlns:rdf=" xmlns:exterms=" xml:base=" Overnighter other product descriptions...

The rdf:type property indicates that the resource being described is an instance of the class identified by the URIref This assumes that example.com has described its classes as part of the same vocabulary used to describe its other terms (e.g., property exterms:weight )  So the absolute URIref of the class is used to refer to it If example.com had described these classes as part of the product catalog itself, the relative URIref #Tent could be used to refer to it RDF itself doesn’t provide facilities for defining application- specific classes of things or their properties  Such classes are described using the RDF Schema language (later)

Resources with rdf:type properties are called  typed nodes in the graph or  typed node elements in the RDF/XML RDF/XML has a special abbreviation for describing typed nodes  The rdf:type property and its value are removed  The rdf:Description element for the node is replaced by an element whose name is the QName corresponding to the value of the removed rdf:type property (a URIref that names a class) Using this abbreviation, we rewrite that previous example as in the next slide

]> <rdf:RDF xmlns:rdf=" xmlns:exterms=" xml:base=" Overnighter other product descriptions...

A resource may be described as an instance of more than one class  So a resource may have more than one rdf:type property  But only 1 of these rdf:type properties can be abbreviated The others must be written out using rdf:type properties The typed node abbreviation is also used in RDF/XML when describing instances of  the built-in RDF classes (e.g., rdf:Ba g ) and  the built-in RDF Schema classes (such as rdfs:Class ) Both are covered later