Section 6.2. Support for Modules in Common Applications

6.2. Support for Modules in Common Applications

Although the modules mentioned herein are in use in at least one installation somewhere in the world, the vast majority of them aren't supported by the most common newsreader applications. Dublin Core is supported by most, but the others are variable in the extreme. This isn't to say that they aren't useful. Far from it. They are just used mostly within private organizations, with private software producing and parsing them. Just because you don't see many people using a module doesn't mean they aren't. But conversely, just because you produce data in a module doesn't mean the general public can read it. These things evolve.


The Administration module, written by Aaron Swartz and Ken Macleod, provides information about the feed's owner and the toolkit used to produce it. This helps the RSS user work with his provider to get things right, and it helps the RSS community at large identify problems with certain systems.

Recommended Usage

It is good manners to include this module as a matter of course. The data isn't dynamically created, so it can be included within a template and just left to do its job.


The namespace prefix for this module is admin:, which should point to Therefore, the root element and the RSS 1.0 module containing mod_admin should look like this:

<rdf:RDF xmlns:rdf="" xmlns="" xmlns:admin="">


The mod_admin elements occur as subelements of channel only. They consist of:

<admin:errorReportsTo rdf:resource= " URI" />

The URI is typically a mailto: URL for contacting the feed administrator to report technical errors.

<admin:generatorAgent rdf:resource= " URI" />

The URI is the home page of the software that generates the feed. If possible, this should be a page that specifies a version number within the URIfor example,


<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:admin="">   <channel rdf:about="">     <title>Content Syndication with RSS</title>     <link></link>     <description>Content Syndication with RSS, the blog</description>     <admin:errorReportsTo rdf:resource=""/>     <admin:generatorAgent rdf:resource=""/> ...


The Aggregation module plays a small but useful part in the lifecycle of information passing through the Web. It allows news aggregators, such as those covered in Chapter 2, to display the sources of their items. These services gather items from many other sources and group them by subject. mod_aggregation lets you know where they originated.

This, of course, works over generations: as long as the mod_aggregation elements are respected, a Meerkat feed that uses a Snewp item from a Moreover feed that is itself an aggregation (for example) still has the original source credited. As long as the mod_aggregation elements are left in place, the information is preserved. There isn't, as yet, any feature for describing an aggregation history, however; you only know about the primary source. You also can't necessarily trust the contents of the element either, but this is more a social issue than a technological one.

Aggregators are the only people generating these elements; if you're building such a system, consider including them. The act of parsing such elements, however, is good for everyone. One can easily envisage an HTML representation of an RSS 1.0 feed with a "link via x" section. This is already done manually by many weblog owners, so why not include the feature in your RSS parsing scripts?


mod_aggregation takes ag: as its prefix and as its identifying URI. Therefore, an RSS 1.0 root element that uses it should look like this:

<?xml version="1.0"?> <rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:ag="" >


mod_aggregation's elements are all subelements of item. There are three, and they are all mandatory if you are using the module:


The name of the source of the item (no character limit)


The URL of the source of the item (no character limit)


The time the item was published by the original source, in the ISO 8601 standard (ccyy-mm-ddThh:mm:ss+hh:mm)


<?xml version="1.0"?> <rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:ag="" >     <channel rdf:about="">     <title>Meerkat</title>     <link></link>     <description>Meerkat: An Open Wire Service</description>   </channel>     <items>     <rdf:Seq>       <rdf:li rdf:resource="" />     </rdf:Seq>   </items>    <item rdf:about="" >     <title>XML: A Disruptive Technology</title> <link></link>     <description>     XML is placing increasingly heavy loads on the existing technical     infrastructure of the Internet.     </description>     <ag:source></ag:source>     <ag:sourceURL></ag:sourceURL>     <ag:timestamp>2000-01-01T12:00+00:00</ag:timestamp>   </item> </rdf:RDF>


mod_annotation is the smallest module. It consists of one element, which refers to a URL where a discussion of the item is being held. It might point to a discussion group, a commenting service, Usenet, an Annotea service, etc.

For sites that host such discussions, the addition of this module into the RSS feed should be simple and worthwhile. Weblogs, for example, might need to point the element only to the URL of the main entry page for a particular item.

If you want to parse this module into HTML, you should, as with many of these modules, have no problems simply assigning a separate div or span for the contents of the element, wrapping it within an <a href=" URL" >, and formatting it as you wish. This would probably make sense only if your parser is also taking notice of either the description element or the data provided by mod_content, simply because it is hard to have a discussion based solely on a headline.


mod_annotation is identified by the namespace prefix annotate: and the URI Hence, the root element looks like this:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:annotate="" >


There's only one element, a subelement of item, and here it is:

<annotate:reference rdf:resource= " URL" />

The URL points to a discussion on the item.

However, this element can also take subelements of its own from the Dublin Core modules, mod_dublincore and mod_DCTerms. We'll see these modules soon, but the first example in the next section will give you an idea.

Do you see how the namespaces system works? The first example shows a feed using only the mod_annotation system. We've added one additional namespace and used the element correctly. In the second example, we want to use another module to describe something in terms that the currently available elements can't. So we decide upon mod_dublincore, add in the namespace declaration, and go ahead.

Also notice that in first example, annotate is a one-line element, with a closing />, whereas in the second example, annotate contains the mod_dublincore elements before closing. This means that the mod_dublincore elements refer to annotate, not to the item or channel. As you'll see, mod_dublincore can get addictive, and you might find yourself describing everything in your feed. This isn't bad at all, but it may get confusing. By paying attention to which elements are within which, you can see what is happening.


The following example shows mod_annotation in action:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:annotate="" > <item rdf:about="">     <title>RSS 0.9 or RSS 1.0...Discuss</title>     <link></link>     <annotate:reference rdf:resource=""/> </item>

The following example shows mod_annotation inside an item element:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:annotate=""          xmlns:dc="" > . . . <item rdf:about="">     <title>RSS 0.9 or RSS 1.0...Discuss</title>     <link></link> <annotate:reference rdf:resource="">       <dc:subject>XML</dc:subject>   <dc:description>A discussion group on the subject in hand</dc:description> </annotate>



mod_audio is the first of the RSS 1.0 modules so far that points at something other than a text page. It is specifically designed for the syndication of MP3 filesits elements matching those of the ID3 tag standardbut it can be used for any audio format.

It was designed by Brian Aker, who also wrote the mp3 module for the Apache web server. That Apache module not only streams MP3s from a server, but also creates RSS playlists.

If you syndicate audio or point at feeds that syndicate audio, this is a must. Also, consider using mod_streaming, the module for streaming.


mod_audio uses the prefix audio: and is indentified by the URI Hence:

<rdf:RDF xmlns:rdf=""           xmlns=""           xmlns:audio="" >


mod_audio elements are all subelements of item. None are mandatory to the module, but you should make an effort to include as many as possible per track.


The title of the song


The name of the artist


The name of the album


The year of the track


Any text comment on the track


The genre of the track (should match genre_id)


The length of the track in seconds


The bit rate of the track, in Kbps


The number of the track on the album


The genre ID number, as defined by the ID3 standard


The price of the track, if you're selling it


<item rdf:about="" >      <title>BoyBand's Latest Track!</title>      <description>The latest track from the fab five.</description>      <link></link>      <audio:songname>One Likes to Get Funky</audio:songname>      <audio:artist>BoyBand</audio:artist>      <audio:album>Not Just Another</audio:album>      <audio:year>2005</audio:year>      <audio:genre>Top 40</audio:genre>      <audio:genre_id>60</audio:genre_id> </item>


It can be said that some of these elements are superfluous because they can be replaced by other elements (for example, audio:songname could be replaced by title). This is true in many cases, but it is much neater to use a simple MP3 tag-reading script to generate the RSS and map ID3 elements across directly. There are many ID3 tag-reading libraries available, including Chris Nandor's MP3::Info for Perl.


mod_changedpage does for RSS 1.0 what the cloud element does for RSS 0.9x: it introduces a form of Publish and Subscribe. We'll discuss Publish and Subscribe in detail in Chapter 9, but basically it enables a system in which you can "subscribe" to a feed and be notified when something new is published.

mod_changedpage uses only one element, which points to a changedPage server. Users wishing to be told when the feed has updated send an HTTP POST request of a certain format to this server. Upon updating, this server sends a similar POST request back to the user. The user's client then knows about the update. Again, Chapter 9 examines this in detail.


mod_changedpage takes the namespace prefix cp: and is identified by the URI Hence, its declaration looks like this:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:cp="">


mod_changedpage takes only one element, a subelement of channel :

<cp:server rdf:resource="URL" />

The URL is the address of the changedPage server.


<?xml version="1.0" encoding="utf-8"?>    <rdf:RDF  xmlns:rdf=""         xmlns=           xmlns:cp="" >   <channel rdf:about="">   <title>Meerkat</title>   <link></link>   <description>Meerkat: An Open Wire Service</description> <cp:server rdf:resource="" /> </channel> ...


mod_company allows RSS feeds to deliver business news metadata. Like mod_audio, this is another example of RSS 1.0 stretching the bounds of RSS functionality; this module could lead to RSS being used as a specialist business news vehicle rather than just a generalized list of links.


mod_company takes the namespace prefix company: and is identified by the URI By now, you'll realize that this means the root element of a RSS 1.0 document containing mod_company will resemble this:

<rdf:RDF xmlns:rdf=""           xmlns=""           xmlns:company="">


mod_company provides four elements, all of which are subelements of item. None are defined as mandatory, but there's little hassle and much reward in including all of them.


The name of the company.


The ticker symbol of the company's stock.


The abbreviation of the market in which the stock is traded.


The category of the company, expressed using the Taxonomy module. For more details, see mod_taxonomy later in this chapter.


<item rdf:about="">     <title>Cisco Stock moves either up or down!</title> <description>A brief story about a thing happening today</description> <link><link>    <company:symbol>CSCO</company:symbol>     <company:market>NASDAQ</company:market>     <company:name>Cisco Systems Inc.</company:name>     <company:category>     <taxo:topic rdf:resource="                                Manufacturers/">     </company:category> </item>


mod_content is perhaps the most misunderstood module of all. Its purpose isn't only to allow much richer contentthe entire site, images and all, for exampleto be included within a RSS 1.0 item, but also to give a complete RDF description of this content. Now, not only can you make RDF graphs from channel to item, but you can also make them from item to an image within an item. An RDF query of "find all feeds that point to articles accompanied by a picture of an elephant" can now be executed easily because mod_content provides not just the content itself, but the relationship metadata as well. It can also be used to split the object to which an item points into smaller sections, from the standpoint of an RDF parser.

The syntax for this can look a little long-windedRDF is rather verbose when written in XMLand, because of this, mod_content feeds can often look scary. They're not really, and reformatting them in a text editor can give you an idea of what is happening. Despite this apparent complexity, it is one of the only modules to have been officially accepted by the rss-dev working group.

It must be noted that mod_content isn't to be confused with the core specification's description subelement of item. Some RSS 1.0 feeds use description to contain the content the item represents. While this may be common practice with RSS 0.9x users, RSS 1.0 users may wish to do it properly. description is for a description of the content; mod_content is for the content itself.


mod_content is identified by the namespace prefix content: and the URI Hence, the root element looks like this:

<rdf:RDF  xmlns:rdf=""           xmlns=""           xmlns:content="">


mod_content is slightly more complex than the other modules; it has a specific structure that must be followed. It consists of one element with various subelements that have important attributes of their own, some of which are mandatory, while others aren't.

The first element, content:items, is a subelement of item. It consists of an rdf:Bag that contains as many content:items as needed, each enveloped in an rdf:li element, as shown in Example 6-1.

Example 6-1. The basic structure of a mod_content item
<item> ... <content:items> <rdf:Bag>   <rdf:li>       <content:item rdf:about=""/>   </rdf:li>   <rdf:li>       <content:item />   </rdf:li> </rdf:Bag> </content:items> </item>

Notice that one of the content:item elements in Example 6-1 has an rdf:about attribute, but the other doesn't. This difference is to show that if the content is available on the Web at a specific address, the rdf:about attribute contains the URI of the content, including any part of the content that is directly addressable (an image, for example). Hence, a deeper RDF relationship level is declared.

Also notice that the content:item element in Example 6-1 is empty. This isn't particularly useful, so let's look into filling it. Content, as you know, can come in many formats: plain text, HTML 4.0, XHTML 1.1, and so on. What you do with such content depends on its format, so mod_content needs to be able to describe the format. It does this with a content:format subelement.

This element takes one attribute, rdf:resource, which points to a URI that represents the format of the content. Basically, this attribute declares the namespace of the content. For example, for XHTML 1.0 Strict, the URI is The URI for HTML 4.0 is Further examples of URIs for different types of content can be found at

The content:format element is required. If you don't include it, you force anyone parsing your feed to guess your content's format.

Because you have declared the format of the content:item using an RDF declaration, you must now envelop the actual content inside an rdf:value element. Example 6-2 shows a simple version.

Example 6-2. A simple version of a mod_content item
<item> ... <content:items>   <rdf:Bag>     <rdf:li>       <content:item>       <content:format rdf:resource="" />         <rdf:value>           <![CDATA[<em>This is<strong>very</em> cool</strong>.]]>         </rdf:value>       </content:item> </rdf:li> </rdf:Bag> </content:items>

Example 6-2 shows a single item that contains a single content:item that itself contains a line of HTML 4.0 reading <em>This is<strong>very</em> cool</strong>. Note that the HTML content is encased in a CDATA section. As with all XML (see Appendix A for details), non-XML-compliant content must be wrapped in this manner inside an RSS feed.

HTML, however, isn't the only content type, and newer content types are fully XML-compliant. XHTML, for example, doesn't need to be wrapped, as long as the parser is made aware that the contents of the rdf:value element can be treated accordingly. For this, you use rdf:value's optional range of attributes, rdf:parseType and xmlns. Example 6-3 shows the same content as Example 6-2, but it's reformatted into XHTML. Note the differences in bold.

Example 6-3. A simple version of a mod_content item, with XHTML
<item> ... <content:items>   <rdf:Bag>     <rdf:li>       <content:item>       <content:format rdf:resource=""/>        <content:encoding rdf:resource=""/>         <rdf:value rdf:parseType="Literal" xmlns="">            <em>This is <strong>very</strong> </em> <strong>cool</strong>.         </rdf:value>       </content:item> </rdf:li> </rdf:Bag> </content:items>

In Example 6-3, we've told the rdf:value element that its contents are both parsable using the namespace represented by the URI We declare all of this to prevent RDF parsers from getting confused. We humans, of course, are anything but.

The content itself is now well-formed XML. To show this, you can include a new subelement of content:item, the optional content:encoding. This points to the rdf:resource of the URI of well-formed XML,

If no content:encoding is present, assume that the content is plain character data, either enclosed in a CDATA section or surrounded by escaped characters such as &lt;b&gt;.

Here are mod content's subelements:


Contains a subelement of rdf:Bag.


Contains one or more subelements of rdf:li.


Contains a mandatory subelement of content:item.


Takes the mandatory subelements content:format and rdf:value, and the optional subelement content:encoding. content:item must take the attribute rdf:about=" URI" if the object can be directly addressed.


Takes the attribute rdf:about=" URI", in which the URI represents the format of the content.


Contains the actual content. It can take two attributes. If its content is well-formed XML, it must take the attributes rdf:Parsetype="literal" and xmlns="".


Takes the attribute rdf:about=" URI", in which the URI represents the format in which the content is encoded.


<item rdf:about="">  <title>The Example Item</title>  <link></link>  <description>I am an example item</description>  <content:items>   <rdf:Bag>       <rdf:li>     <content:item>     <content:format rdf:resource="" />     <content:encoding rdf:resource="" />      <rdf:value rdf:parseType="Literal" xmlns="">       <em>This is a <strong>very cool</strong> example of mod_content</em>      </rdf:value>     </content:item>    </rdf:li>       <rdf:li>     <content:item>      <content:format rdf:resource="" />      <rdf:value>       <![CDATA[You can include content in lots of formats. <a        href="">links</a> too. ]]>      </rdf:value>     </content:item>    </rdf:li>   </rdf:Bag>  </content:items> </item>

It may either amuse or terrify you to realize that because content:item can contain any XML-formatted content, it can itself contain other RSS feeds. This might be useful for a RSS tutorial web site, syndicating its lessons. The next example is an early version of this very section of this book, represented as an item, up to this paragraph to prevent a spiral of recursion.

<title>Examples</title> <description>The text of the first part of the Examples section of the mod_content  bit of chapter 6 of Content Syndication with XML and RSS</description> <content:items> <rdf:Bag> <rdf:li> <content:item> <content:format rdf:resource="" /> <rdf:value> <![CDATA[ <h2>Examples</h2>]]> </rdf:value> </content:item> </rdf:li> <rdf:li> <content:item> <content:format rdf:resource="" /> <content:encoding rdf:resource="" /> <rdf:value rdf:parseType="Literal"                xmlns=""               xmlns:rdf=""               xmlns:content=""> <item rdf:about=""><title>The Example Item</title> <link></link> <description>I am an example item</description> <content:items><rdf:Bag><rdf:li><content:item> <content:format rdf:resource="" /> <content:encoding rdf:resource="" /> <rdf:value rdf:parseType="Literal" xmlns=""><em> This is a <strong>very cool</strong> example of mod_content</em></rdf:value></ content:item></rdf:li> <rdf:li><content:item> <content:format rdf:resource="" /> <rdf:value><![CDATA[You can include content in lots of formats. <a href="http://www.">links</a> too. ]]></rdf:value></content:item></rdf:li></rdf:Bag></ content:items></item> </rdf:value> </content:item> </rdf:li> <rdf:li> <content:item> <content:format rdf:resource="" /> <rdf:value><![CDATA[ <p><i> Example 6.12 A fully mod_contented &lt;item&gt;</i></p><p> It may either amuse or terrify you to realize that as &lt;content:item&gt can contain any  XML-formatted content, it can itself contain other RSS feeds. This might be of use for a  RSS tutorial website, syndicating its lessons. Here, in example 6.13, is this very section of this  book, represented as an &lt;item&gt;, stopping right here to prevent a spiral of  recursion.</p>]]> </rdf:value> </content:item> </rdf:li> </rdf:Bag> </content:items> </item>


The second of the Standard modules to be examined in this chapter, mod_dublincore is the most-used of all the RSS 1.0 modules. It allows an RSS 1.0 feed to express the additional metadata formalized by the Dublin Core Metadata Initiative.


mod_dublincore is identified by the prefix dc: and the URI So, in the grand tradition, the root element appears as:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:dc="" >


mod_dublincore can be used in two ways: the simpler and the more RDF-based.

In either usage, mod_dublincore elements are entirely optional and can be applied to the channel, an item, an image, a textinput element, or all of them, as liberally as you wish, as long as the information you are relating makes sense. It is rather addictive, I must say, and I encourage you to put Dublin Core metadata all over your feeds. Here's what you can include:


The title of the item.


The name of the creator of the item (i.e., a person, organization, or system). If the creator is a person, this information is customarily in the format Firstname Lastname (email @ domain. com).


The subject of the item.


A brief description of the item.


The name of the publisher, either a person or an organization. If the publisher is a person, this information is customarily in the format Firstname Lastname (email @ domain. com).


The name of a contributor, customarily in the format Firstname Lastname (email @ domain. com).


The publishing date, in the W3CDTF format (e.g., 2000-01-01T12:00+00:00).


The nature of the item, taken from the list of Dublin Core types at


A collection is an aggregation of items, described as a group; its parts can be described and navigated separately (for example, a weblog).


A dataset is information encoded in a defined structure (for example, lists, tables, and databases), intended to be useful for direct machine processing.


According to the official definition of the Dublin Core authors, an event is a nonpersistent, time-based occurrence. Examples include any exhibition, webcast, conference, workshop, open-day, performance, battle, trial, wedding, tea party, conflagration, or orgy. The soon-to-be-described mod_event has a lot to do with this sort of thing.


They are worth a thousand words, you know.

Interactive resource

The official Dublin Core definition of an interactive resource is "a resource which requires interaction from the user to be understood, executed, or experienced. For exampleforms on web pages, applets, multimedia learning objects, chat services, virtual reality." In the RSS world, resources could be either pointers to programs or the textinput element itself.


Technically, a service is a system that provides one or more functions of value to the end user. Assuming that just providing information doesn't count, a service can point to web applications or web services, as long as you create an RSS feed that provides the necessary details (using mod_content to syndicate WSDL files, for example).


You know what software is. In this case, it is distinguished from an interactive resource by being downloadable rather than run on a remote server.


Officially, a sound is a resource with content primarily intended to be rendered as audio.


Plain-text content.


This differs from dc:type by a degree of sophistication. Whereas dc:type provides a top-level indication of the feed's nature, dc:format should point to the exact MIME type of the content itself.


The identifier should be an unambiguous reference to the resource within a given context. So, in RSS 1.0 terms, this is the same as the item's rdf:about attribute.


In RSS 1.0 terms, this element can do the same job as the ag:sourceURL of the mod_aggregation module. It should point to an unambiguous reference to the source of the item. Unlike the ag:sourceURL element, however, dc:source isn't restricted to URLs. Any sufficiently unambiguous reference works (ISBNs, for example).


The language in which the item is written, using the standard language code, as covered in Appendix B.


The URI of a related resource. See mod_DCTerms later in this chapter for more details.


According to the Dublin Core authors, "coverage will typically include spatial location (a place name or geographic coordinates), temporal period (a period label, date, or date range), or jurisdiction (such as a named administrative entity). Recommended best practice is to select a value from a controlled vocabulary (for example, the Thesaurus of Geographic Names [TGN]) and that, where appropriate, named places or time periods be used in preference to numeric identifiers such as sets of coordinates or date ranges."


This element should contain any copyright, copyleft, public domain, or similar declaration. The absence of this element doesn't imply anything whatsoever.

The more complex version of mod_dublincore adds RDF and the mod_taxonomy module to give a richer meaning to dc:subject. For example, dc:subject can be used simply like this:

<dc:subject>World Cup</dc:subject>

or combined with a definition of a topic, in a richer RDF version:

<dc:subject>   <rdf:Description>     <taxo:topic rdf:resource="" />     <rdf:value>World Cup</rdf:value>   </rdf:Description> </dc:subject>

This not only defines the subject but also provides it with a wider contextual meaning. In this example, we're saying the subject is "the World Cup of soccer" (or more correctly, we're saying that "this item is on the subject represented by the term `World Cup' in the context provided by the URI") After all, there is more than one World Cup. This approach is especially useful for describing homonyms, such as:

<dc:subject>   <rdf:Description>     <taxo:topic rdf:resource=" Food_and_Related_Products/Beverages/Soft_Drinks" />     <rdf:value>Coke</rdf:value>   </rdf:Description> </dc:subject>

as opposed to:

<dc:subject>   <rdf:Description>     <taxo:topic rdf:resource=" Illegal_Drugs/" />     <rdf:value>Coke</rdf:value>   </rdf:Description> </dc:subject>


<rdf:RDF xmlns:rdf=""   xmlns=""   xmlns:dc="" > <channel rdf:about="">   <title>Meerkat</title>   <link></link>   <description>Meerkat: An Open Wire Service</description>   <dc:publisher>The O'Reilly Network</dc:publisher>   <dc:creator>Rael Dornfest (</dc:creator>   <dc:rights>Copyright &#169; 2000 O'Reilly &amp; Associates, Inc.</dc:rights>   <dc:date>2000-01-01T12:00+00:00</dc:date>   <dc:type>Interactive Resource</dc:type>   <image rdf:resource="" />   <textinput rdf:resource="" />    <items>     <rdf:Seq>       <rdf:li resource="" />     </rdf:Seq>   </items> </channel> <image rdf:about="">   <title>Meerkat Powered!</title>   <url></url>   <link></link>   <dc:creator> Rael Dornfest (</dc:creator>   <dc:type>image</dc:type> </image> <textinput rdf:about="">   <title>Search Meerkat</title>   <description>Search Meerkat's RSS Database...</description>   <name>s</name>   <link></link> </textinput> <item rdf:about="">   <title>XML: A Disruptive Technology</title>   <link></link>   <dc:description>This the description of the article</dc:description>   <dc:publisher>The O'Reilly Network</dc:publisher>   <dc:creator>Simon St.Laurent (</dc:creator>   <dc:rights>Copyright &#169; 2000 O'Reilly &amp; Associates, Inc.</dc:rights>   <dc:subject>XML</dc:subject> </item>



Once Dublin Core metadata has sunk its I-must-add-metadata-to-everything addictive nature into your very soul, you soon realize that the core terms are lacking in depth. For example, dc:relation means "is related to," but in what way? You don't know unless you use mod_DCTerms.

mod_DCTerms introduces 28 new subelements to channel, item, image, and textinput, as appropriate. These subelements are related, within Dublin Core, to the core elements found within mod_dublincore, but mod_DCTerms doesn't express this relationship. For example, dcterms:created is actually a refinement of dc:date.


mod_DCTerms takes the namespace prefix dcterms: and is identified by the URI So, the root element looks like this:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:dcterms="" >


You have a lot to choose from with this module. As shown earlier, the elements can be subelements of channel, item, image, or textinput. Apply liberally and with gusto.


An alternative title for the item. For example:

<title>Programming Perl</title> <dc:title>Programming Perl</dc:title> <dcterms:alternative>The Camel Book</dcterms:alternative>


The date the object was created, in W3CDTF standard (YYYY-MM-DDTHH:MM:SS).


The date the object was first made available. This should be used, for backward compatibility, with dc:date, and it should contain the same value. Again, the date must be in W3CDTF format.


The date the content of the object last changed, in W3CDTF format. This can sit inside channel, item, or both.


The size of the document referred to by the section of the feed in which the element appears, in bytes.


The HTTP Content-Type of the object to which the parent element refers. The HTTP Content-Type is made up of the MIME type followed optionally by the character set, denoted by the string ;charset=. For example:

<dcterms:medium>text/html; charset=UTF-8</dcterms:medium>

Paired Elements

Some mod_DCterms elements come paired together naturally. When talking about two separate items, it's important to remember that the following paired elements must work together:

dcterms:isVersionOf and dcterms:hasVersion

This pair of elements works together to point to different versions of an object. For example, you can use it to list versions in different languages or different formats. Their values should point to each other, should be URIs, and, for complete RDF compatibility, should be encased in an rdf:resource attribute. There is also nothing to stop you from providing further information about the version via additional RDF markup, like so:

<dcterms:hasVersion rdf:resource=" URI of resource"> <dc:title>Title of other resource</dc:title> </dcterms:hasVersion>

dcterms:isReplacedBy and dcterms:replaces

Denotes an item that points to a more recent version of the object in question. The syntax is the same as the dcterms:isVersionOf pair; it takes an rdf:resource attribute that points to the URI of the object in question.

dcterms:isRequiredBy and dcterms:requires

Denotes an object relationship in which, according to the Dublin Core specification, "the described resource requires the referenced resource to support its function, delivery, or coherence of content." As you might expect by now, this pair takes the attribute rdf:resource to denote the URI of the object to which you're pointing and may be augmented by additional RDF.

dcterms:isPartOf and dcterms:hasPart

The mod_DCTerms elements have quite self-explanatory names, and this pair is no exception. It denotes objects that are subsections of other objects. It's the traditional syntax of an rdf:resource attribute with the option of additional RDF within the element.

dcterms:isReferencedBy and dcterms:references

A pair in which one object refers to or cites the other. Its syntax is the usual drillan rdf:resource attribute and some additional RDF if you're feeling generous.

dcterms:isFormatOf and dcterms:hasFormat

This final pair of elements denotes two objects that contain the same intellectual content but differ in format. For example, one object could be a color PDF and the other a Word document. The syntax is the same as the other paired elements but with the additional recommendation that you include dc:format, dc:language, or another element that helps the end user tell the difference between the two separate versions. Also bear in mind that URIs must be unique, so anyone using content negotiation on his server must give different URIs for each format, whether or not it is actually necessary.

Using DCSV Values

There are three mod_DCTerms elements that take a special syntax to denote a timespan. This syntax, Dublin Core Structured Values (DCSV), represents complex values together in one simple string. It takes the following format (all the attributes are optional):

name= Associated name; start= Start time; end= End time; scheme=W3C-DTF;


This element denotes any timespan of the item's subject matter. For example:

<dcterms:temporal> name=World War 2; start=1939; end=1945; scheme=W3C-DTF; </dcterms:temporal>


This denotes the timespan during which the item's contents are valid. For example:

<dcterms:valid>start=20030101; end=200300201;  scheme=W3C-DTF;</dcterms:valid>


This denotes the timespan during which the object to which the item points is available (i.e., network-retrievable).


mod_event really breaks RSS 1.0 out of the datacentric model and into the real world. It's purpose is to describe details of real-world events. You can then use this data in your calendar applications, display it on a page, email it; use it for whatever purpose you like.

According to Søren Roug, the module's author, "This specification isn't a reimplementation of RFC 2445 iCalendar in RDF. In particular, it lacks such things as TODO and repeating events, and there is no intention of adding those parts to the specification."


The events module takes the shapely ev: as its namespace prefix, and it is identified by the pleasingly regular So, the root element looks like this:

<?xml version="1.0" encoding="utf-8"?>    <rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:ev="" >


The mod_events elements are all subelements of item. None of them are mandatory, but common sense should prevail regarding usage: the more the better.


The time and date of the start of the event, in W3CDTF format.


The time and date of the end of the event, in W3CDTF format.


The location of the event. This can be a simple string or a URI, or it can be semantically augmented via RDF. For example:

<ev:location>At Ben's house</ev:location>




<ev:location rdf:resource=""> <rdf:value> y=124&mapdata=xU4YXdELrnB2xoPaJ66QjsffE4Zu%252bP6OZQy2y1Ah8EPehGZcP7zX7a3LAujflI 6g%252boY5z8%252b7lqnLexYmGmo96xAPLE%252bMe4H2TaN0PDMZ5pH9rjsN3owqiP9AOg8%252fOX tNlI1FGCb4fddEaWl23DGyUhXfazgpROqIrCGP%252fmKvh2vwRs0lc8k9F0ltIpaTc%252foiXwyvfB CMSvv2EAvYEbNgn6ztUAlmEA%252bK2tqfR5jD9QRdgA0yRNovXEpgRakMia3g2jRzTo06OcbL8TDJru fAn11sl6d5CQUD8xjR1nJj3ieObeWOVwRB0w8T4MSHFQLg9SoPaSN3LMG2PixeD2X5%252bs4Sg3K1JS 4LqmvDON%252bugHKDenLg%252b%252fxQhtVGFuhugqWLosZ%252fSo2wQ7Y%253d&click=center </rdf:value> </ev:location>


The name of the organizer of the event. Again, you can semantically augment this element to include more information. For example:

<ev:organizer>Ben Hammersley</ev:organizer>


According to the specification, this should be "the type of event, such as conference, deadline, launch, project meeting. The purpose is to promote or filter out certain types of events that the user has a particular (lack of) interest for. Avoid the use of subject-specific wording. Use instead the Dublin Core subject element."


<rdf:RDF xmlns:rdf=""   xmlns:ev=""   xmlns:dc=""   xmlns="" >   <channel rdf:about="">     <title>O'Reilly Events</title>     <link></link>     <description>O'Reilly Events</description>     <items>       <rdf:Seq>         <rdf:li resource="" />         <rdf:li resource="" />       </rdf:Seq>     </items>   </channel>   <item rdf:about="">     <title>The O'Reilly Peer-to-Peer and Web Services Conference</title>     <link></link>     <ev:type>conference</ev:type>     <ev:organizer>O'Reilly</ev:organizer>     <ev:location>Washington, DC</ev:location>     <ev:startdate>2001-09-18</ev:startdate>     <ev:enddate>2001-09-21</ev:enddate>     <dc:subject>P2P</dc:subject>   </item>   <item rdf:about="">     <title>Programming Web Services with XML-RPC</title>     <link></link>     <ev:startdate>2001-06-20</ev:startdate>     <ev:type>book release</ev:type>     <dc:subject>XML-RPC</dc:subject>     <dc:subject>Programming</dc:subject>   </item>



The mod_rss091 module is designed to give RSS 1.0 "sideways compatibility" with RSS 0.91. Because the three core subelements of the item element are the same in both standards, including mod_rss091 elements in your RSS 1.0 feed allows for dynamic downgrading of the feed for parsers that can't be bothered with all the RDF stuff. Because the data is rather simple and mostly static, including this module within your RSS 1.0 feed is straightforward. With this in mind, it's worth doing.


The prefix for this module is the self-explanatory rss091:, and the module is represented by the URI Hence:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:rss091="" >


The mod_rss091 elements represent the same elements within RSS 0.91. Chapter 4 provides details on those elements.

Subelements of channel


The language of the feed


The PICS rating of the feed


The managing editor of the feed


The webmaster of the feed


The publication date of the feed


The date of the feed's last build


The copyright notice of the feed

rss091:skipHours rdf:parseType="Literal"

The skipHours element, with correct RDF syntax


The hours, in GMT, during which the feed shouldn't be retrieved

rss091:skipDays rdf:parseType="Literal"

The skipDays element, with correct RDF syntax


The days during which a feed shouldn't be retrieved (Monday is 1, and Sunday is 7)

Subelements of image


The width of the image


The height of the image

Subelement of item


The description of the item. While this element is replicated by core RSS 1.0, it is listed here for the sake of completion.


<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:rss091="" >   <channel rdf:about="">     <title></title>     <link></link>     <description> features a rich mix of information and services for the XML community.     </description>     <rss091:language>en-us</rss091:language>     <rss091:rating>(PICS-1.1 ""      l gen true comment "RSACi North America Server"      for "" on "1996.04.16T08:15-0500"      r (n 0 s 0 v 0 l 0))</rss091:rating>     <rss091:managingEditor>Edd Dumbill</rss091:managingEditor>     <rss091:webmaster>(</rss091:webmaster>     <rss091:pubDate>Sat, 01 Jan 2000 12:00:00 GMT</rss091:pubDate>     <rss091:lastBuildDate>Sat, 01 Jan 2000 12:00:00 GMT</rss091:lastBuildDate>     <rss091:skipHours rdf:parseType="Literal">     <rss091:hour>12</rss091:hour>     </rss091:skipHours>     <rss091:skipDays rdf:parseType="Literal">     <rss091:day>Thursday</rss091:day>     </rss091:skipDays>   </channel>   <image rdf:about="">     <title></title>     <link></link>     <url></url>     <rss091:width>88</rss091:width>     <rss091:height>31</rss091:height>     <rss091:description></rss091:description>   </image>   <item rdf:about="" position= "1">      <title>Processing Inclusions with XSLT</title>      <link></link>      <rss091:description>      Processing document inclusions with general XML tools can be problematic.      This article proposes a way of preserving inclusion information through      SAX-based processing.      </rss091:description>   </item>



mod_servicestatus is one of the latest RSS 1.0 modules. Its purpose is to allow RSS 1.0 to display details of the status and current availability of services and servers.

You should bear in mind the difference between services and servers. One service may rely on more than one server in the back end. For the user, however, such information is irrelevant: something either works or it doesn't. With mod_servicestatus, you can't differentiate between a virtual service and an actual physical server, but you can combine servers into services at the parsing stage. This means one feed can be used for multiple things: a detailed display for sysadmins and a simplified version for end users.


The mod_servicestatus prefix is ss:, and the module is identified by the URI So, a mod_servicestatus feed starts like this:

<rdf:RDF xmlns:rdf=""        xmlns=""          xmlns:ss="" >


The first element of mod_servicestatus is a subelement of channel:


A URI that points to a page explaining the results and methodology being used

All other elements within mod_servicestatus are subelements of item. As with many modules, all these elements are optional, but the more you include, the more fun you'll have.


This can be either TRue or false, and it refers to whether the server is responding.


The date and time the server was last checked, in W3CDTF format.


The date and time the server last responded, in W3CDTF format. Used with ss:lastChecked, this enables you to work out down times.


A figure that describes server availability. Usually an integer percentage, this should be explained in the document referenced by ss:aboutStats.


The average response time of the server, usually in seconds. This should also be explained in the ss:aboutStats document.


A message aimed at the end user. For example: "We know this is broken, and we're working on it," or "Please log out, pushing of the Big Red Button is imminent," or "Run for the door! Run! Run!"


<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:ss="" > <channel rdf:about="">   <title>An Example</title>   <description>Just an example of system statuses</description>   <link></link> <ss:aboutStats></ss:aboutStats>   <items>     <rdf:Seq>       <rdf:li resource="" />       <rdf:li resource="" />     </rdf:Seq>   </items> </channel> <item rdf:about="">   <title>Website</title>   <link></link>   <ss:responding>true</ss:responding>   <ss:lastChecked>2002-05-10T19:20:30.45+01:00</ss:lastChecked>   <ss:lastSeen>2002-05-10T19:20:30.45+01:00</ss:lastSeen>   <ss:availability>85</ss:availability>   <ss:averageResponseTime>5.2</ss:averageResponseTime> </item> <item rdf:about="">   <title>Database server</title>   <link></link>   <ss:responding>false</ss:responding>   <ss:lastChecked>2002-05-10T19:20:30.45+01:00</ss:lastChecked>   <ss:lastSeen>2002-05-09T13:43:56.24+01:00</ss:lastSeen>   <ss:availability>77</ss:availability>   <ss:averageResponseTime>12.2</ss:averageResponseTime>   <ss:statusMessage>Engineers are investigating.</ss:statusMessage> </item> </rdf:RDF>


Slash is the software originally written to run the popular technology news site Slashdot. It has spread quite far lately, and now hundreds of sites use it for their content management system. Slash's unique features don't fit into the core RSS 1.0 specification, so Rael Dornfest and Chris Nandor wrote this module. The features are most easily understood after a look at a Slash-based site, so go over to to see what's happening.


The namespace prefix is slash:, and the identifying URI is Hence:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:slash="" >


All the mod_slash elements are subelements of item. They are all mandatory.


The title of the section in which the article appears.


The title of the department in which the article appears (in most Slash sites, this title is a joke).


The number of comments attached to an article.


A comma-separated list of the number of comments displayable at each karma threshold (this will make sense if you look at a Slash-based site). There should be seven figures, matching karma thresholds of -1, 0, 1, 2, 3, 4, and 5.


<item rdf:about=""> <title>LotR Two Towers Trailer Online</title> <link></link> <dc:creator>CmdrTaco</dc:creator> <dc:subject>movies</dc:subject> <dc:date>2002-07-01T17:08:24+00:00</dc:date> <slash:department>provided-you-have-sorenson-and-bandwidth</slash:department> <slash:section>articles</slash:section> <slash:comments>20</slash:comments> <slash:hitparade>20,19,11,8,3,0,0</slash:hitparade> </item>


mod_streaming was designed by me (happily enough) to take care of the additional needs of anyone who wants to create a feed that points to streaming-media presentations. You will notice elements for the live eventsstart times, end times, and so forth. These can also split a single stream into chunks and provide associated metadata with each section.


mod_streaming takes str: as its prefix, and is its identifying URI. So, its root element looks like this:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:str="" >


All the elements within mod_streaming are subelements of item except str:type, which can be a subelement of channel as well. All elements are optional.


This can take audio, video, or both as its value, and it can be a subelement of either item or channel. video implies a video, regardless of the presence of a soundtrack. both implies a mixture of video and audio items, and hence is used only within a channel description.


The name of any special application required to play back the stream.


The version number of the associated application, if applicable.


The URI for downloading the associated application.


The name of the codec in which the stream is encoded.


The version number of the codec, if applicable.


The URI for downloading the codec.


The value of any audio's sample rate, in kHz.


Either stereo or mono, depending on the audio being used.


The number of pixels in the X axis (width).


The number of pixels in the Y axis (height).


The length of the item, in the W3C format of HH:MM:SS.

str: live

Either live or recorded, as applicable.


A W3CDTF-encoded date and time for the start of live broadcasts, or just for the start time in the time code of a recording.


The end time of a live broadcast or recording, in the same format as str:live.scheduledStartTime.


This can be a literal string, as per the Dublin Core location guidelines, or it can use RDF with additional location-specific namespaces.


A URI to contact the live show (e.g., mailto:, http:, aim:, or irc:). Think "radio phone-in show."


<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:str="" > <channel rdf:about="">   <title>Streams R Us</title>   <link></link>   <description>Streams R Us: An Entirely Fictional Site</description>   <str:type>both</str:type>   <image rdf:resource="" /> <items>   <rdf:Seq>     <rdf:li rdf:resource="" />     <rdf:li rdf:resource="" />     <rdf:li rdf:resource="" />   </rdf:Seq> </items> </channel> <item rdf:about="">   <title>RSS Rocks Out</title>   <link></link>   <str:associatedApplication>realplayer</str:associatedApplication>   <str:associatedApplication.downloadUri>   </str:associatedApplication.downloadUri>   <str:duration>00:04:30</str:duration>   <str:live>recorded</str:live> </item> <item rdf:about="">   <title>RSS Rocks Out Live</title>   <link></link>   <str:associatedApplication>winamp</str:associatedApplication>   <str:associatedApplication.downloadUri>   </str:associatedApplication.downloadUri>   <str:duration>00:04:30</str:duration>   <str:live>live</str:live>   <str:live.scheduledStartTime>2002:04:03T00:00:00Z</str:scheduledStartTime>   <str:live.scheduledEndTime>2002:04:03T00:04:30Z</str:scheduledEndTime> </item> <item rdf:about="">   <title>RSS Rocks Out Live on Video</title>   <link></link>   <str:type>video</str:type>   <str:codec>sorenson</str:codec>   <str:associatedApplication>Quicktime</str:associatedApplication>   <str:associatedApplication.downloadUri>   </str:associatedApplication.downloadUri>   <str:duration>00:02:32</str:duration>   <str:live>live</str:live>   <str:live.scheduledStartTime>2002:04:03T00:00:00Z</str:scheduledStartTime>   <str:live.scheduledEndTime>2002:04:03T00:02:32Z</str:scheduledEndTime>   <str:codec.ResolutionX>600</str:codec.ResolutionX>   <str:codec.ResolutionY>400</str:codec.ResolutionY>   <str:live.ContactUri></> </item>



mod_syndication gives aggregators and feed users an idea of how often the feed changes. By giving this information, you prevent everyone from wasting time and bandwidth by asking for your feed too often or, indeed, too seldom. It is the third module to achieve Standard status.

mod_syndication supersedes the skipHours and skipDays elements of mod_rss091. Clients usually prefer the mod_syndication values over mod_rss091.


mod_syndication takes sy: as its prefix and as its identifying URI. Thus:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:sy="" >


The mod_syndication elements are all subelements of channel:


Takes a value of hourly, daily, weekly, monthly, or yearly.


A number representing the number of times the feed should be refreshed during the updatePeriod. For example, an updatePeriod of hourly and an updateFrequency of 2 makes the aggregator refresh the feed twice an hour. If this element is missing, the default is 1.


The date and time, in W3CDTF format, from which all calculations should originate.


<channel rdf:about=""> <title>Meerkat</title> <link></link> <description>Meerkat: An Open Wire Service</description> <sy:updatePeriod>hourly</sy:updatePeriod> <sy:updateFrequency>2</sy:updateFrequency> <sy:updateBase>2000-01-01T12:00+00:00</sy:updateBase>


mod_taxonomy allows the classification of objects under a defined taxonomic scheme; basically, you describe the topics of your objects.

The object can be anything: a channel, an item, or a reference from another module. Because of this universality, mod_taxonomy can be used heavily throughout an RSS 1.0 feed, which may cause some confusion. As with many modules, a good bit of reformatting may help clarify things.

The taxonomic definitions are always given as URIs. As shown in Chapter 5, URIs are used, like namespaces, to differentiate between homonyms. Python (the language) and Python (the snake) need to be distinguished, because you may want to run away from one of them. Snakes are generally cuddly, after all.

The Open Directory Project, at, is a good source of taxonomic URIs. All the examples in this section originate from this source.


mod_taxonomy takes the stylish moniker of taxo: and the identifying URI of Hence, the lovely root element:

<rdf:RDF xmlns:rdf=""   xmlns=""   xmlns:taxo="" >


mod_taxonomy can be used in two ways: the simple and the more defined. The simple method uses one element, and it can be used as a subelement of item or channel:

<taxo:topics> <rdf:Bag> <rdf:li resource=" URI to taxonomic reference" / <rdf:li resource=" URI to taxonomic reference" /> </rdf:Bag> </taxo:topics>

This nesting of elements gives a list of topics that are associated with the channel or the item that contains it. This structure remains the same, with additional <rdf:li resource=""/> elements for every new topic.

This provides a straightforward method for giving a list of defining URIs for an RSS object. Sometimes, however, you might want to define more details of each of the topic URIs themselves. For this, use the taxo:topic element. This element is a subelement of rdf:RDFi.e., on the same level as channel, item, and so on.

Within the grammar of RDF, taxo:topic allows you to assign metadata to the URI used elsewhere in the feed in taxo:topics. It takes one subelement of its own module, taxo:link, and then any other module's element that can be a subelement of channel. The most popular elements come from mod_dublincore:

<taxo:topic rdf:about=" URI of taxonomic resource"> <taxo:link>URL to taxonomic resource<taxo:link> <dc:subject>Example</dc:subject> Other elements here </taxo:topic>

The taxo:topic element itself can contain taxo:topics, as shown in the following section.


<item rdf:about="" position="1">   <title>XML: A Disruptive Technology</title>   <link></link>   <description>   XML is placing increasingly heavy loads on the existing technical   infrastructure of the Internet.   </description>   <taxo:topics>     <rdf:Bag>      <rdf:li resource="">      <rdf:li resource="">      <rdf:li resource="">     </rdf:Bag>   </taxo:topics> </item> <taxo:topic rdf:about="">   <taxo:link></taxo:link>   <dc:title>Data: XML</taxo:title>   <dc:description>A Meerkat channel</dc:description> </taxo:topic> <taxo:topic rdf:about="">   <taxo:link></taxo:link>   <dc:title>XML</taxo:title>   <dc:subject>XML</dc:subject>   <dc:description>DMOZ category</dc:description>   <taxo:topics>    <rdf:Bag>     <rdf:li resource="">     <rdf:li resource="">     <rdf:li resource="">     </rdf:Bag>   </taxo:topics> </taxo:topic>

This example shows an item using taxo:topics to describe itself and a taxo:topic defining two of the taxonomic definitions used. The last taxo:topic uses taxo:topics itself to define its own subject with more finesse.

Note that the taxo:topic elementswhich define the URIs we use within the <item><taxo:topics></taxo:topics></item> sectionare on the same level as the item within the document. RSS 1.0's structure, unlike RSS 0.9x, gives them both equal weight.


mod_threading provides a system to describe the children of an item (for example, replies to a weblog entry). This module is still in a state of flux; a great deal of work is being done by many people on the idea of descriptions of message threads within RSS and RDF. This is one of the goals of the ThreadML development effort (

With this in mind, mod_threading can get complicated quickly. Unfortunately, as complex as you might logically make it, the lack of standardization means that anything but the simplest usage will likely be misunderstood by most parsers. Therefore, in this chapter we restrict ourselves to defining children only within the limited scope of a single document. If true message threading is your goal, check with the mailing lists and weblogs linked to by the ThreadsML effort for more details.


mod_threading takes the prefix thr: and the identifying URI Hence, the root element:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:thr="" >


There's only one element within mod_threading; it's a subelement of item*, and it contains an rdf:Seq containing rdf:li elements of URIs representing items that are children of the item:

<thr:children>   <rdf:Seq>     <rdf:li rdf:resource="URI OF CHILD ITEM" />   </rdf:Seq> </thr:children>

For simplicity's sake, the child item, and hence the URI, must be also contained within the same RSS 1.0 document.


<item rdf:about="">     <title>XML: A Disruptive Technology</title>     <link></link>     <thr:children>      <rdf:Seq>        <rdf:li rdf:resource=""/>        <rdf:li rdf:resource=""/>        <rdf:li rdf:resource=""/>      </rdf:Seq>    </thr:children> </item>


Wikisweb pages that grant editing rights to everyoneare increasingly popular, but they give RSS feed creators plenty of special problems. Because wikis contain extensive information about how the page has been edited, and by whom, they require their own module to supply all the necessary elements.


mod_wiki's prefix is wiki:, and the identifying URI is mod_wiki also uses mod_dublincore for some of its elements. Hence, the lovely root element:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:dc=""          xmlns:wiki=""  >



An optional subelement of channel, wiki:interwiki refers to the moniker of the wiki in question if it is part of an interwiki setup. It can take two forms, between which you may choosethe simpler:

<wiki:interwifi>INTERWIKI MONIKER<wiki:interwiki>

or the more complex, which may be unparsable for simple parsers:

<wiki:interwiki>   <rdf:Description link="URL TO WIKI">     <rdf:value>WIKI NAME</rdf:value>   </rdf:Description> </wiki:interwiki>


An optional subelement of item containing the version number of the page.


An optional subelement of item denoting it as new, updated, or deleted.


An optional subelement of item describing the importance of the change to the page (either major or minor).


An optional subelement of item that provides a URL to the previous version of the page.


An optional subelement of item that provides a URL to a list of changes to the page.


A special optional subelement of the dc:contributor element from mod_dublincore. It contains the IP address of the person who made the change to the wiki page. It should be in the following format:

<dc:contributor>   <rdf:Description wiki:host="">     <rdf:value>A.N.Person</rdf:value>   </rdf:Description> </dc:contributor>


<item rdf:about=" pl?action=browse&amp;id=JohnKellden&amp;revision=30">   <title>JohnKellden</title>   <link></link>   <description></description>   <dc:date>2002-07-03T06:47:19+00:00</dc:date>   <dc:contributor>   <rdf:Description wiki:host="" >   <rdf:value></rdf:value>   </rdf:Description>   </dc:contributor>   <wiki:status>updated</wiki:status>   <wiki:importance>major</wiki:importance> <wiki:diff> pl?action=browse&amp;diff=4&amp;id=JohnKellden</wiki:diff> <wiki:version>30</wiki:version>   <wiki:history>;id=JohnKellden</ wiki:history>



The mod_prism module allows an RSS 1.0 feed to express metadata terms formalized by the PRISM initiative of IDEAlliance, a publisher and information technology forum. PRISM stands for Publishers Requirements for Industry Standard Metadata and aims to describe content assets from trade serial publications for syndication. PRISM defines a small set of vocabularies that work together to address industry requirements for resource discovery. Adopting the Dublin Core vocabulary (with certain qualifications), PRISM defines an additional basic vocabulary of some 50 terms, plus three smaller, more specialized vocabularies for dealing with rights, inline markup, and controlled vocabularies. This module defines the basic PRISM vocabulary and is frequently used together with the Dublin Core module.

It should be noted that this description of the mod_prism was kindly written by Tony Hammond, a coauthor of the specification itself. Many thanks to him.


mod_prism is identified by the prefix prism: and the URI Because PRISM uses Dublin Core, it is common practice (though by no means required) to see both the PRISM and Dublin Core namespaces declared together. So, the root element typically appears as:

<rdf:RDF xmlns:rdf=""          xmlns=""          xmlns:dc=""          xmlns:prism="" >


The basic PRISM vocabulary has some 50 terms, far too many to detail here. If you want to experience the full panoply of PRISM, see the actual module for a complete listing and explanation. (That module, in turn, references the PRISM specification, which is the authoritative source for all definitions.) What I'll try to do here is list a few common elements that occur in bibliographic citations and some basic rights terms, and show how these are being used in actual feeds from science publishers to disseminate tables of content alerts.


Copyright statement for the resource.


ISSN for an electronic version of the issue in which the resource occurs.


ISSN for the publication in which the resource was published.


Indication of the magazine issue. This element is intended to be used with the prism:volume element to specify the magazine issue using the common scheme of Volume and Number.


Announced date and time when the resource is released to the public.


Title of the magazine, or other publication, in which a resource is/will be published.


Name, and possibly contact information, for the person or organization that should be contacted to license the rights to use a resource.


Name of the magazine section in which the resource was categorized.


Identifies the first page number for the published version of the resource.


Additional identifier for the publication in which the resource appeared, providing the Volume portion of the common Volume/Number scheme.


This example is taken from Nature, the well-known weekly scientific magazine. Note especially the use of the rdfs:seeAlso link, which points to the previous issue in the series. In this way, the complete collection of issues can be made available and linked together. RSS isn't just for breaking news but can also be used to deliver archival feeds. There is just as much value (and sometimes more) in the older stories.

<?xml version="1.0" encoding="utf-8"?> <rdf:RDF    xmlns:rdf=""    xmlns:rdfs=""    xmlns=""    xmlns:dc=""    xmlns:prism="" > <channel rdf:about="">   <title>Nature</title>   <description>International weekly journal of science</description>   <link></link>   <rdfs:seeAlso rdf:resource="                                                        n7012/rss.rdf"/>   <dc:publisher>Nature Publishing Group</dc:publisher>   <dc:language>en</dc:language>   <dc:rights>Copyright © 2004 Nature Publishing Group</dc:rights>   <prism:publicationName>Nature</prism:publicationName>   <prism:issn>0028-0836</prism:issn>   <prism:eIssn>1476-4679</prism:eIssn>   <prism:copyright>Copyright © 2004 Nature Publishing Group</prism:copyright>   <prism:rightsAgent></prism:rightsAgent>   <image rdf:resource=""/>   <items>     <rdf:Seq>         <rdf:li rdf:resource=""/>     </rdf:Seq>   </items> </channel> <image rdf:about="">     <title>Nature</title>     <url></url>     <link></link> </image> <item rdf:about="">     <title>Climate change clouds commercial licence to krill</title>     <link></link>     <description>Emma Marris</description>     <dc:title>Climate change clouds commercial licence to krill</dc:title>     <dc:creator>Emma Marris</dc:creator>     <dc:identifier>doi:10.1038/432004a</dc:identifier>     <dc:source>Nature 432, 4 (2004)</dc:source>     <dc:date>2004-11-04</dc:date>     <prism:publicationName>Nature</prism:publicationName>     <prism:publicationDate>2004-11-04</prism:publicationDate>     <prism:volume>432</prism:volume>     <prism:number>7013</prism:number>     <prism:section>News</prism:section>     <prism:startingPage>4</prism:startingPage> </item>


    Developing Feeds with RSS and Atom
    Developing Feeds with Rss and Atom
    ISBN: 0596008813
    EAN: 2147483647
    Year: 2003
    Pages: 118 © 2008-2017.
    If you may any questions please contact us: