| [ Team LiB ] |
|
4.1 ContainersAs I was writing this book, the RDF Working Group issued a document titled "Refactoring RDF/XML Syntax" detailing modifications to the RDF Model and Syntax Specification. One of the major changes to the specification was a modification related to RDF containers, the subject of this section. However, since the recommended modifications were fairly extensive, they couldn't be covered within a note. I rewrote this section of the book only to have the Working Group somewhat reverse itself as to the legitimacy of containers—containers would be included in the RDF/XML syntax, but their meaning would be constrained. To ensure a proper perspective of containers, the next section contains an overview of containers as they were modeled in the original specification; a section detailing the changes from the refactoring follows. Finally, at the end I summarize containers as they are understood in the newest release of the RDF Syntax Specification. 4.1.1 Containers as Covered Within the Initial Specification ReleaseResource properties can occur singly or in groups. To this point, we've looked at recording only individual properties, but RDF needs to record multiply occurring properties. The creators of the RDF syntax were aware of this and created the concept of RDF Containers specifically for handling multiple resources or for handling multiple literals (properties). Each of the several types of RDF Containers has different behaviors and constraints.
The first container we'll look at is rdf:Bag, containing unordered lists of resources or literals, with duplicate data allowed. An example of a Bag could be an inventory of photographs, whereby the sequence that the photos are listed in isn't relevant. Example 4-1 demonstrates an RDF document using a Bag. Example 4-1. Group of photo resources contained within an RDF Bag<?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/earthstars/contest.htm"> <pstcn:photos> <rdf:Bag> <rdf:li rdf:resource="http://burningbird.net/earthstars/capo.jpg" /> <rdf:li rdf:resource="http://burningbird.net/earthstars/baritea.jpg" /> <rdf:li rdf:resource="http://burningbird.net/earthstars/cfluorite.jpg" /> <rdf:li rdf:resource="http://burningbird.net/earthstars/ccinnibar.jpg" /> <rdf:li rdf:resource="http://burningbird.net/earthstars/baryto.jpg" /> <rdf:li rdf:resource="http://burningbird.net/earthstars/cbarite2a.jpg" /> </rdf:Bag> </pstcn:photos> </rdf:Description> </rdf:RDF> Figure 4-1 shows the RDF graph for this RDF/XML. Figure 4-1. RDF graph of RDF Bag Container Within the RDF Validator, the elements of the Bag are also given labels of _1, _2, and so on; automated processes identify each individual element in the container with an automatically generated number, preceded by an underscore ( _ ). In addition, the validator also provides a unique identifier for the resource bubble representing the Bag of the format genid:number, where number is, again, an automatically generated number representing the resource. In the example, the listed items within the RDF container are identified with an RDF rdf:li or list item tag, similar in semantics to the HTML li tag. Each resource is identified with a resource attribute. If the container contained literals instead of resources as items, then the format used for each item would be similar to the following: <rdf:li>Barite Photo</rdf:li> A second type of container is the sequence, or rdf:Seq. An rdf:Seq groups resources or literals, just as a Bag does, but unlike with rdf:Bag, the ordering of the contained elements is considered significant and is indicated by the ordering of the rdf:_n membership properties. As with rdf:Bag, duplicate resources or literals are allowed. If you're grouping web pages within a menu on your main web page, you'll most likely want to group the pages in RDF in such a way that the order of the grouping is maintained. Using rdf:Seq, automated procedures can pick up the pages and add them to your menu as new resources are added. An example of the RDF file to support this is shown in Example 4-2. Example 4-2. Group of menu resources contained within an RDF Sequence<?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/earthstars/contest.htm">
<pstcn:menu>
<rdf:Seq>
<rdf:li rdf:resource="http://burningbird.net/articles.htm" />
<rdf:li rdf:resource="http://burningbird.net/dynatech.htm" />
<rdf:li rdf:resource="http://burningbird.net/interact.htm" />
</rdf:Seq>
</pstcn:menu>
</rdf:Description>
</rdf:RDF>
The last container type is the Alternative container, rdf:Alt. This container variation provides alternatives for a specific value. An excellent use for it is a listing of expressions written in different languages, such as a greeting or label for a user interface item. The application that processes the RDF would then pick the alternative based on a locale setting for the environment in which the application is running. The rdf:Alt syntax does not differ from that of the rdf:Bag and rdf:Seq, except for the element name. However, there must be at least one item within an rdf:Alt container, to act as the default value for the resource—the first member listed. Earlier I mentioned that a resource identifier could be a URI or an identifier to a URI given elsewhere in the RDF document. The latter is particularly helpful when using RDF Containers, providing a way to associate information with the group of items. Example 4-3 demonstrates how this would work with the RDF shown in Example 4-2. Example 4-3. Grouping an RDF Description and identifier to attach information to a container<?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/earthstars/contest.htm">
<pstcn:menu>
<rdf:Description rdf:about="#menuitems">
<pstcn:menu>Links to additional resources</pstcn:menu>
</rdf:Description>
</pstcn:menu>
</rdf:Description>
<rdf:Seq rdf:ID="menuitems">
<rdf:li rdf:resource="http://burningbird.net/articles.htm" />
<rdf:li rdf:resource="http://burningbird.net/dynatech.htm" />
<rdf:li rdf:resource="http://burningbird.net/interact.htm" />
</rdf:Seq>
</rdf:RDF>
In the original container specification, the document refers to the individual container items as referents. To specifically associate a statement with each referent rather than with the container as a whole, the rdf:aboutEach attribute was to be used with the RDF Description, rather than rdf:about: <rdf:Description aboutEach="#menuitems"> When this type of statement is applied to container elements, they're then referred to as distributive referents. Though not restricted specifically to the Bag container within the RDF syntax, the aboutEach attribute is usually associated with the Bag due to the unordered nature of the Bag's items. Another RDF attribute for Bag elements is rdf:aboutEachPrefix. This is used to associate information about each resource within a specific directory or web location. If used with Example 4-3, it would look like this: <rdf:Decription aboutEachPrefix="http://burningbird.net"> <pstcn:phototype>JPEG</pstcn:phototype> </rdf:Description> Instead of using an RDF Container for groups of properties, you can repeat the property (the predicate), modifying the value assigned to the property (the object) with each: <rdf:Description rdf:about="http://burningbird.net/articles/monsters3.htm">
<pstcn:Contains>Physical description of giant squids</pstcn:Contains>
<pstcn:Contains>Tale of the Legendary Kraken</pstcn:Contains>
</rdf:Description>
Which you use depends on whether you want to refer to the collection of items as a singular unit or not. If you do, you would use the Container; otherwise, you would most likely use the repeated property, as the syntax is simpler. This section contained a description of containers as implemented in the original RDF Model and Syntax document. This description changed dramatically during the re-examination of the RDF specification, as detailed next. 4.1.2 Containers as Typed NodesThe RDF Working Group states the following:
The RDF Working Group and people implementing RDF solutions had two concerns about containers: first, that the functionality represented with containers can be expressed with the typed node production, leading to confusion about which representation should be used to express a specific statement; second, that RDF applications have to have special knowledge of containers in order to interpret the rdf:li elements—unlike other RDF elements, rdf:li elements get translated into numbered elements with the format of _1, _2, and so on. To deal with both of these issues, the group released a document, "Refactoring RDF/XML Syntax" (at http://www.w3.org/TR/2001/WD-rdf-syntax-grammar-20010906/) that recommended the removal of all special container constructs; container-like behavior will be implemented with typed node productions instead. At first glance, this looked to be a significant change, and I was concerned about its impact on my own RDF implementations as well as this book. However, the Working Group assured us that these changes are to the specification and not necessarily changes to the syntax represented by the specification. As contradictory as this first sounds, closer examination of the changes does reflect that, though the specification is modified, the actual syntax remains the same. This can be proven by taking a closer look at containers and reinterpreting them as typed nodes: how would something such as the container RDF in Example 4-1 fit within this newly modified syntax? In the original specification, rdf:li elements are translated into sequentially numbered elements of the format rdf:_n—rdf:_1, rdf:_2, and so on. Within the newly modified specification, rdf:li elements are still translated into numbered elements; however, you can also specify the numbered elements directly yourself or mix elements, though the results of such mixing may be unexpected. Example 4-4 shows a modification of the RDF/XML shown in Example 4-2 that fits within the newly modified specification. Example 4-4. Container as typed node<?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/earthstars/contest.htm">
<pstcn:menu>
<rdf:Seq>
<rdf:_1 rdf:resource="http://burningbird.net/articles.htm" />
<rdf:li rdf:resource="http://burningbird.net/dynatech.htm" />
<rdf:li rdf:resource="http://burningbird.net/interact.htm" />
</rdf:Seq>
</pstcn:menu>
</rdf:Description>
</rdf:RDF>
The use of the Seq container type is still allowed; however, rather than representing a specific container construct, it now represents a typed node. The following would provide the same results: <pstcn:MyBag> <rdf:_1 rdf:resource="http://burningbird.net/articles.htm" /> <rdf:li rdf:resource="http://burningbird.net/dynatech.htm" /> <rdf:li rdf:resource="http://burningbird.net/interact.htm" /> </pstcn:MyBag> Implicit with both the rdf:Seq and the custom element is a type statement associated with the node automatically when the type attribute isn't provided. When the RDF Validator parses Example 4-4, you might expect that the numbering of the rdf:li nodes would begin with rdf_2, following from the value set for the first contained element, rdf:_1. This isn't the result and won't be the result from the RDF triples associated with the test cases; numbering begins with rdf:_1 for each grouping and isn't impacted by manual settings of the other contained and grouped elements. How does this fit the typed node syntax? Remembering that associated with an element such as rdf:Seq is a type=URI property assignment, the following steps map the EBNF of the typed node production directly to the instance diagrammed in Example 4-4: <rdf:Seq> is derived directly from '<' typeName propAttr* '>'
where typeName = QName and
QName = rdf:Seq
where propAttr is the implicit type=URI for Seq
<rdf:_1> is derived directly from propertyElt
where propertyElt = '<' propName idRefAttr '/>'
where propName = QName
QName = rdf:_1
where idRefAttr = resourceAttr
resourceAttr = ' resource="' URI-Reference '"'
And so on for the other properties. As you can see, the container instance does map directly to the typed node production, and there is no loss of functionality based on dropping the container-specific syntax. However, just when I was starting to become comfortable with replacing the Container with a typed node, the Working Group reversed itself and included support for Containers—with modifications and a whole lot of annotations about "meaning." 4.1.3 Containers TodayContainers are included within the RDF/XML Syntax Specification, but without some of the supporting attributes, such as rdf:aboutEach and rdf:aboutEachPrefix, which have been removed from the syntax. The key to the current status of Containers is this sentence within the specification (as it existed in its Last Call state):
The Container classes of rdf:Seq, rdf:Bag, and rdf:Alt are still in the documentation, with an understanding that these may be replaced with typed node productions. And this does impose an implication constraint on the container classes—as typed node productions, no additional semantics as to the application of containers can exist outside of what could be implied with typed nodes. From an application perspective, containers are a grouping of related items, each of which can be given a unique list property, represented by rdf:li within RDF/XML, or more properly, rdf:_n, with the value of n representing the ordering within the container (if ordering is implied by the container, such as rdf:Seq). Example 4-5 is a valid use of containers, in this case an rdf:Seq with its intended semantic assumptions of ordering of the members of the container. Example 4-5. "Container" implemented using custom container-like class<?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/earthstars/contest.htm">
<pstcn:menu>
<rdf:Seq>
<rdf:_1 rdf:resource="http://burningbird.net/articles.htm" />
<rdf:_2 rdf:resource="http://burningbird.net/dynatech.htm" />
<rdf:_3 rdf:resource="http://burningbird.net/interact.htm" />
</rdf:Seq>
</pstcn:menu>
</rdf:Description>
</rdf:RDF>
The RDF/XML in Example 4-4 could be replaced with the RDF/XML in Example 4-5, and the meaning associated with the construction would be the same; the resulting RDF graph replaces all rdf:li items with rdf:_n items based on the position of the item within the container, as shown in Figure 4-2. The rdf:li property is a construct of the RDF/XML syntax only and not a part of the RDF graph (or associated RDF data model). Figure 4-2. Graph of custom typed node production emulating RDF Container class
There are intended but not formally described semantics associated with rdf:Seq — that the contained items are ordered and that the number of items in rdf:Bag is finite and unordered and duplicates are allowed. There are also intended but not formally described semantics with rdf:Alt that each item is an option, with the first item being the default if no other is specified. However, there is nothing within the RDF specification that formally requires applications heed these intended semantics, other than general consensus. In fact, the documented semantics surrounding containers are quite vague, which, in my opinion, makes the use of containers suspect. Because of this, I recommend caution when using containers. |
| [ Team LiB ] |
|
