the rdf/xml serialization rdf statements can be written in rdf/xml very much like descriptions in...

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

<http://www.example.org/index.html>

exterms:creation-date "August 16, 1999" .

In N3

@prefix exterms: <http://www.example.org/terms/> .

<http://www.example.org/index.html>

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<?xml version="1.0"?>

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns:exterms="http://www.example.org/terms/">

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

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

</rdf:RDF>

The 1st 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 definitions

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .


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


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

</rdf:Description>

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 http://www.w3.org/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 N3


@prefix dc: <http://purl.org/dc/elements/1.1/> .

<http://www.example.org/index.html> exterms:creation-date

"August 16, 1999" .

<http://www.example.org/index.html> dc:lang "en" .

Any number of statements could be added in this way, using a separate rdf:Description element for each

The RDF/XML:

<?xml version="1.0"?>


xmlns:dc="http://purl.org/dc/elements/1.1/"




</rdf:Description>


<dc:language>en</dc:language>

</rdf:Description>

</rdf:RDF> 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 slide


@prefix exstaff: <http://www.example.org/staffid/> .


<http://www.example.org/index.html> exterms:creation-date

"August 16, 1999" .

<http://www.example.org/index.html> dc:language "en" .

<http://www.example.org/index.html> dc:creator exstaff:85740 .

The corresponding RDF/XML







<dc:language>en</dc:language>

<dc:creator rdf:resource="http://www.example.org/staffid/85740"/>

</rdf:Description>

</rdf:RDF> New feature

A new feature in the line <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>

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

“http://www.example.org/staffid/85740”

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:Description rdf:about="http://www.example.org/index.html"

dc:language="en"

exterms:creation-date="August 16, 1999">

<dc:creator rdf:resource="http://www.example.org/staffid/85740"/>

</rdf:Description>

</rdf:RDF>

Blank Nodes (Bnodes) Consider the English statement

“The document http://www.w3.org/TR/rdf-syntax-grammar has a title ‘RDF/XML Syntax Specification (Revised)’ and has an editor, whose name is ‘Dave Beckett’, and a home page http://purl.org/net/dajobe/.”

In N3


@prefix exterms: <http://example.org/stuff/1.0/> .

<http://www.w3.org/TR/rdf-syntax-grammar>

dc:title "RDF/XML Syntax Specification (Revised)";

exterms:editor [ exterms:fullName "Dave Beckett";

exterms:homepage <http://purl.org/net/dajobe/>] .

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 <http://purl.org/net/dajobe/> .

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




xmlns:exterms="http://example.org/stuff/1.0/">

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">

<dc:title>RDF/XML Syntax Specification (Revised)</dc:title>

<exterms:editor rdf:nodeID="abc"/>

</rdf:Description>

<rdf:Description rdf:nodeID="abc">

<exterms:fullName>Dave Beckett</exterms:fullName>

<exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>

</rdf:Description>

</rdf:RDF>

A bnode can be written so that the <rdf:Description> </rdf:Description> 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




xmlns:exterms="http://example.org/stuff/1.0/">

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"

dc:title="RDF/XML Syntax Specification (Revised)">

<exterms:editor rdf:parseType="Resource">

<exterms:fullName>Dave Beckett</exterms:fullName>

<exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>

</exterms:editor>

</rdf:Description>

</rdf:RDF>

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




xmlns:ex="http://example.org/stuff/1.0/">



<ex:editor rdf:parseType="Resource">

<ex:fullName>Dave Beckett</ex:fullName>

</ex:editor>

</rdf:Description>

</rdf:RDF>

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




xmlns:ex="http://example.org/stuff/1.0/">



<exterms:editor exterms:fullName="Dave Beckett" />

</rdf:Description>

</rdf:RDF>

It’s easy to read this as

“The document http://www.w3.org/TR/rdf-syntax-grammar 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

http://www.w3.org/2001/XMLSchema#

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:Description>

</rdf:RDF>

The following changes untyped literal August 16, 1999 to something equivalent to the N3 typed literal

"1999-08-16"^^xsd:date





<exterms:creation-date rdf:datatype=

"http://www.w3.org/2001/XMLSchema#date">

1999-08-16

</exterms:creation-date>

</rdf:Description>

</rdf:RDF>

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="http://www.w3.org/2001/XMLSchema#date"

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

[

<!ENTITY client "Mr. R. Jones">

<!ENTITY agent "Ms. B. Smith">

<!ENTITY phone "<number>617-555-1299</number>">

]>

<message>

<opening>Dear &client;</opening>

<body>

To reserve a place for your holiday in

Piñata, Mexico, call &agent; at &phone;

</body>

</message>

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 numbered named

mixed-content unparsed

internal external

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

"http://www.w3.org/2001/XMLSchema#"

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:

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>

Note the “#”

Can now replace the URIref

"http://www.w3.org/2001/XMLSchema#date"

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






<exterms:creation-date rdf:datatype="&xsd;date">

1999-08-16

</exterms:creation-date>

</rdf:Description>

</rdf:RDF>

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 http://www.example.org/index.html 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

<html>

<head>

<title>Illustrating Fragment Identifiers</title>

</head>

<body>

<h4>Frying an Egg</h4>

<ul>

<li><a href="#step1">Step 1</a></li>



</ul>

<br /> <br /> <br /> <br /> <br />

<a name="step1"></a>

<h5>Step 1</h5>

<p>Break the egg in the heated frying pan.</p>Continued

<br /> <br /> <br /> <br /> <br />


<h5>Step 2</h5>

<p>Leave the egg in the pan until it's done</p>

<br /> <br /> <br /> <br /> <br />


<h5>Step 3</h5>

<p>Take the egg out of the pan.</p>

</body>

</html>

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

http://www.LArtDeLaCuisine/cookinEggs.html

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

http://www.LArtDeLaCuisine/cookinEggs.html#step1

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)

http://www.example.com/2002/04/products

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




xmlns:exterms="http://www.example.com/terms/">

<rdf:Description rdf:ID="item10245">

<exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>

<exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>

<exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>

<exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>

</rdf:Description>

...other product descriptions...

</rdf:RDF>

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

http://www.example.com/2002/04/products#item10245

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




xmlns:sportex="http://www.exampleRatings.com/terms/">

<rdf:Description

rdf:about="http://www.example.com/2002/04/products#item10245">

<sportex:ratingBy rdf:datatype="&xsd;string">

Richard Roe

</sportex:ratingBy>

<sportex:numberStars rdf:datatype="&xsd;integer">

5

</sportex:numberStars>

</rdf:Description>

</rdf:RDF>

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

http://mirror.example.com/2002/04/products

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

http://mirror.example.com/2002/04/products#item10245

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




xmlns:exterms="http://www.example.com/terms/"

xml:base="http://www.example.com/2002/04/products">


<exterms:model rdf:datatype="&xsd;string">

Overnighter

</exterms:model>



<exterms:packedSize rdf:datatype="&xsd;integer">

784

</exterms:packedSize>

</rdf:Description>


</rdf:RDF>

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:type rdf:resource="http://www.example.com/terms/Tent"/>


Overnighter

</exterms:model>




784


</rdf:Description>


</rdf:RDF>

The rdf:type property indicates that the resource being described is an instance of the class identified by the URIref

http://www.example.com/terms/Tent

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






<exterms:Tent rdf:ID="item10245">


Overnighter

</exterms:model>




784


</exterms:Tent>


</rdf:RDF>

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:Bag) and

the built-in RDF Schema classes (such as rdfs:Class)

Both are covered later

the rdf/xml serialization rdf statements can be written in rdf/xml very much like descriptions in...

Documents