3.6 RDF/XML Shortcuts

An RDF/XML shortcut is just what it sounds like—an abbreviated technique you can use to record one specific characteristic of an RDF model within RDF/XML. In the last section, we looked at using a shortcut to embed a resource's type with the resource definition. Other RDF/XML shortcuts you can use include:

• Separate predicates can be enclosed within the same resource block.

• Nonrepeating properties can be created as resource attributes.

• Empty resource properties do not have to be formally defined with description blocks.

The first shortcut or abbreviated syntax—enclosing all predicates (properties) for the same subject within that subject block—is so common that it's unlikely you'll find RDF/XML files that repeat the resource for each property. However, the RDF/XML in Example 3-13 is equivalent to that shown in Example 3-15.

Example 3-15. Fully separating each RDF statement into separate XML block

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pstcn="http://burningbird.net/postcon/elements/1.0/">
  <rdf:Description rdf:about="http://dynamicearth.com/articles/monsters3.htm">
    <pstcn:author>Shelley Powers</pstcn:author>
  </rdf:Description>
  <rdf:Description rdf:about="http://burningbird.net/articles/monsters3.htm">
    <pstcn:title>Architeuthis Dux</pstcn:title>
  </rdf:Description>
</rdf:RDF>

If you try this RDF/XML within the RDF Validator, you'll get exactly the same model as you would with the RDF/XML from Example 3-1.

The RDF/XML from Examples Example 3-1 and Example 3-13 also demonstrates that you can generate an RDF graph from RDF/XML, but when you then convert it back into RDF/XML from the graph, you won't always get the same RDF/XML that you started with. In this example, the graph for both RDF/XML documents would most likely reconvert back to the document shown in Example 3-1, rather than the one shown in Example 3-13.

For the second instance of abbreviated syntax, we'll again return to RDF/XML in Example 3-1. Within this document, each of the resource properties is listed within a separate XML element. However, using the second abbreviated syntax—nonrepeating properties can be created as resource attributes—properties that don't repeat and are literals can be listed directly in the resource element, rather than listed out as separate formal predicate statements.

Rewriting Example 3-1 as Example 3-16, you'll quickly see the difference with this syntactic shortcut.

Example 3-16. Original RDF/XML document rewritten using an abbreviated (shortcut) syntax

<?xml version="1.0"?>
<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:pstcn="http://burningbird.net/postcon/elements/1.0/">
  <rdf:Description rdf:about="http://burningbird.net/articles/monsters3.htm"
    pstcn:author="Shelley Powers"
    pstcn:title="Architeuthis Dux" />
</rdf:RDF>

As you can see, this greatly simplifies the RDF/XML. RDF parsers interpret the XML in Examples Example 3-1 and Example 3-14 as equivalent, as you can see if you run this newer example through the RDF Validator.

There are actually two different representations of the third abbreviation type, having to do with formalizing predicate objects that are resources. In the examples, RDF resources have been identified within the <rdf:Description>...</rdf:Description> tags, using a formal striped XML syntax format, even if the resource is an object of the statement rather than the subject. However, the rdf:Description block doesn't have to be provided if the resource objects match one of two constraints.

The first constraint is that the resource object must have a URI but must not itself have predicates. It is an empty element. For instance, to record information about documents that are related to the document being described, you could use a related predicate with an rdf:resource value giving the document's URI, as shown in Example 3-17.

Example 3-17. Using rdf:resource to identify an empty resource object

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pstcn="http://burningbird.net/postcon/elements/1.0/">
  <rdf:Description rdf:about="http://burningbird.net/articles/monsters3.htm">
    <pstcn:Author>Shelley Powers</pstcn:Author>
    <pstcn:Title>Architeuthis Dux</pstcn:Title>
    <pstcn:related rdf:resource="http://burningbird.net/articles/monsters1.htm" />
   </rdf:Description>
</rdf:RDF>

You can also use the rdf:resource attribute to designate a resource that's described later in the document. This is an especially useful technique if a resource object is identified early on, but you didn't know if the object had properties itself. If you discover properties for the object at a later time, a separate rdf:Description can be defined for the resource object, and the properties added to it.

In Example 3-17, the related resource object is shown without properties itself. In Example 3-18, properties for this resource have been given, in this case a reason that the resource object is related to the original resource.

Example 3-18. Using rdf:resource to identify a resource that's defined later in the document

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pstcn="http://burningbird.net/postcon/elements/1.0/">
  <rdf:Description rdf:about="http://burningbird.net/articles/monsters3.htm">
    <pstcn:Author>Shelley Powers</pstcn:Author>
    <pstcn:Title>Architeuthis Dux</pstcn:Title>
    <pstcn:related rdf:resource="http://burningbird.net/articles/monsters1.htm" />
   </rdf:Description>

  <rdf:Description rdf:about="http://burningbird.net/articles/monsters1.htm">
    <pstcn:reason>First in the series</pstcn:reason>
  </rdf:Description>
</rdf:RDF>

Of course, this wouldn't be RDF if there weren't options in how models are serialized with RDF/XML. Another variation on using rdf:resource for an object resource is to identify the property object as a resource and then use the shortcut technique shown earlier—adding predicates as attributes directly. With this, you wouldn't need to define a separate rdf:Description block just to add the related property's reason. In fact, Example 3-19 shows all of the shortcut techniques combined to simplify one RDF/XML document.

Example 3-19. RDF/XML document demonstrating all RDF/XML shortcuts

<?xml version="1.0"?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:pstcn="http://burningbird.net/postcon/elements/1.0/">
  <pstcn:Article 
    pstcn:author="Shelley Powers" 
    pstcn:title="Architeuthis Dux" 
    rdf:about="http://dynamicearth.com/articles/monsters3.htm" >
    <pstcn:related rdf:resource="http://burningbird.net/articles/monsters1.htm"
        pstcn:reason="First in the series" />
  </pstcn:Article>

</rdf:RDF>

Again, running this example through the validator results in a graph that's identical to that given if more formalized RDF/XML were used, as shown in Figure 3-7.

Figure 3-7. RDF directed graph of RDF/XML document created using shortcut techniques shown in Example 3-19

Which syntax should you use, formal or shortcut? According to the W3C Syntax Specification (revised), applications that can generate, query, or consume RDF are expected to support both the formal syntax and the abbreviated syntax, so you should be able to use both, either separately or together. The abbreviated syntax is less verbose, and the RDF model documented within the RDF is more clearly apparent. In fact, according to the specification, a benefit of using the abbreviated syntax is that the RDF model can be interpreted directly from the XML (with the help of some carefully designed DTDs).

What do I mean by that last statement? As an example, within the formal syntax, RDF properties are included as separate tagged elements contained within the outer RDF Description element. Opening an XML file such as this using an XML parser, such as in a browser, the properties would display as separate elements—connected to the description, true, but still showing, visibly, as separate elements.

Using the second form of the abbreviated syntax, the properties are included as attributes within the description tag and therefore don't show as separate elements. Instead, they show as descriptive attributes of the element being described, the resource. With rules and constraints enforced through a DTD, the attributes can be interpreted, directly and appropriately, within an XML document using an XML parser (not a specialized RDF parser) as a resource with given attributes (properties) — not an element with embedded, nested elements contained within an outer element.

This same concept of direct interpretation of the RDF model applies to nested resources. Using the formal syntax, a property that's also a resource is listed within a separate Description element and associated to the original resource through an identifier. An XML parser would interpret the two resources as separate elements without any visible association between the two. Using the abbreviated syntax, the resource property would be nested within the original resource's description; an XML parser would show that the resource property is a separate element, but associated with the primary resource by being embedded within the opening and closing tags of this resource.