Section 6.2. Support for Modules in Common Applications
6.2. Support for Modules in Common ApplicationsAlthough 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 UsageIt 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. NamespaceThe namespace prefix for this module is admin:, which should point to http://webns.net/mvcb/. Therefore, the root element and the RSS 1.0 module containing mod_admin should look like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:admin="http://webns.net/mvcb/">ElementsThe mod_admin elements occur as subelements of channel only. They consist of:
Example<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:admin="http://webns.net/mvcb/"> <channel rdf:about="http://rss.benhammersley.com/index.rdf"> <title>Content Syndication with RSS</title> <link>http://rss.benhammersley.com</link> <description>Content Syndication with RSS, the blog</description> <admin:errorReportsTo rdf:resource="mailto:ben@benhammersley.com"/> <admin:generatorAgent rdf:resource="http://www.movabletype.org/?v=2.1"/> ...
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? Namespacemod_aggregation takes ag: as its prefix and http://purl.org/rss/modules/aggregation 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="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:ag="http://purl.org/rss/1.0/modules/aggregation/" > Elementsmod_aggregation's elements are all subelements of item. There are three, and they are all mandatory if you are using the module:
Example<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:ag="http://purl.org/rss/1.0/modules/aggregation/" > <channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0"> <title>Meerkat</title> <link>http://meerkat.oreillynet.com</link> <description>Meerkat: An Open Wire Service</description> </channel> <items> <rdf:Seq> <rdf:li rdf:resource="http://c.moreover.com/click/here.pl?r123" /> </rdf:Seq> </items> <item rdf:about="http://c.moreover.com/click/here.pl?r123" > <title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123</link> <description> XML is placing increasingly heavy loads on the existing technical infrastructure of the Internet. </description> <ag:source>XML.com</ag:source> <ag:sourceURL>http://www.xml.com</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. Namespacemod_annotation is identified by the namespace prefix annotate: and the URI http://purl.org/rss/1.0/modules/annotate/. Hence, the root element looks like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:annotate="http://purl.org/rss/1.0/modules/annotate/" >ElementThere's only one element, a subelement of item, and here it is:
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. ExamplesThe following example shows mod_annotation in action: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:annotate="http://purl.org/rss/1.0/modules/annotate/" > <item rdf:about="http://www.example.com/item1"> <title>RSS 0.9 or RSS 1.0...Discuss</title> <link>http://www.example.com/item1</link> <annotate:reference rdf:resource="http://www.example.com/discuss/item1"/> </item> The following example shows mod_annotation inside an item element: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:annotate="http://purl.org/rss/1.0/modules/annotate/" xmlns:dc="http://purl.org/dc/elements/1.1/" > . . . <item rdf:about="http://www.example.com/item1"> <title>RSS 0.9 or RSS 1.0...Discuss</title> <link>http://www.example.com/item1</link> <annotate:reference rdf:resource="http://www.example.com/discuss/item1"> <dc:subject>XML</dc:subject> <dc:description>A discussion group on the subject in hand</dc:description> </annotate> </item>
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. Namespacemod_audio uses the prefix audio: and is indentified by the URI http://media.tangent.org/rss/1.0/. Hence: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:audio="http://media.tangent.org/rss/1.0/" >Elementsmod_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.
Example<item rdf:about="http://www.example.com/boyband.mp3" > <title>BoyBand's Latest Track!</title> <description>The latest track from the fab five.</description> <link>http://www.example.com/boyband.mp3</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> ApplicationsIt 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. Namespacemod_changedpage takes the namespace prefix cp: and is identified by the URI http://my.theinfo.org/changed/1.0/rss/. Hence, its declaration looks like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:cp="http://my.theinfo.org/changed/1.0/rss/">Elementmod_changedpage takes only one element, a subelement of channel :
Example<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns=http://purl.org/rss/1.0/ xmlns:cp="http://my.theinfo.org/changed/1.0/rss/" > <channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0"> <title>Meerkat</title> <link>http://meerkat.oreillynet.com</link> <description>Meerkat: An Open Wire Service</description> <cp:server rdf:resource="http://example.org/changedPage" /> </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. Namespacemod_company takes the namespace prefix company: and is identified by the URI http://purl.org/rss/1.0/modules/company. 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="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:company="http://purl.org/rss/1.0/modules/company/">Elementsmod_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.
Example<item rdf:about="http://www.example.com/financial_news/00001.html"> <title>Cisco Stock moves either up or down!</title> <description>A brief story about a thing happening today</description> <link>http://www.example.com/financial_news/00001.html<link> <company:symbol>CSCO</company:symbol> <company:market>NASDAQ</company:market> <company:name>Cisco Systems Inc.</company:name> <company:category> <taxo:topic rdf:resource="http://dmoz.org/Computers/Data_Communications/Vendors/ 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. Namespacesmod_content is identified by the namespace prefix content: and the URI http://purl.org/rss/1.0/modules/content/. Hence, the root element looks like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:content="http://purl.org/rss/1.0/modules/content/">Elementsmod_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 http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict. The URI for HTML 4.0 is http://www.w3.org/TR/html4/. Further examples of URIs for different types of content can be found at http://www.rddl.org/natures/. 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="http://www.w3.org/TR/html4/" /> <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="http://www.w3.org/1999/xhtml"/> <content:encoding rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed"/> <rdf:value rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml"> <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 http://www.w3.org/1999/xhtml. 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, http://www.w3.org/TR/REC-xml#dt-wellformed. 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 <b>. Here are mod content's subelements:
Examples<item rdf:about="http://example.org/item/"> <title>The Example Item</title> <link>http://example.org/item/</link> <description>I am an example item</description> <content:items> <rdf:Bag> <rdf:li> <content:item> <content:format rdf:resource="http://www.w3.org/1999/xhtml" /> <content:encoding rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed" /> <rdf:value rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml"> <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="http://www.w3.org/TR/html4/" /> <rdf:value> <![CDATA[You can include content in lots of formats. <a href="http://www.oreillynet.com">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="http://www.w3.org/TR/html4/" /> <rdf:value> <![CDATA[ <h2>Examples</h2>]]> </rdf:value> </content:item> </rdf:li> <rdf:li> <content:item> <content:format rdf:resource="http://purl.org/rss/1.0/" /> <content:encoding rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed" /> <rdf:value rdf:parseType="Literal" xmlns="http://purl.org/rss/1.0/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/"> <item rdf:about="http://example.org/item/"><title>The Example Item</title> <link>http://example.org/item/</link> <description>I am an example item</description> <content:items><rdf:Bag><rdf:li><content:item> <content:format rdf:resource="http://www.w3.org/1999/xhtml" /> <content:encoding rdf:resource="http://www.w3.org/TR/REC-xml#dt-wellformed" /> <rdf:value rdf:parseType="Literal" xmlns="http://www.w3.org/1999/xhtml"><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="http://www.w3.org/TR/html4/" /> <rdf:value><![CDATA[You can include content in lots of formats. <a href="http://www. oreillynet.com">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="http://www.w3.org/TR/html4/" /> <rdf:value><![CDATA[ <p><i> Example 6.12 A fully mod_contented <item></i></p><p> It may either amuse or terrify you to realize that as <content:item> 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 <item>, 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. Namespacemod_dublincore is identified by the prefix dc: and the URI http://purl.org/dc/elements/1.1/. So, in the grand tradition, the root element appears as: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" >Elementsmod_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 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="http://dmoz.org/Sports/Soccer/" /> <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 http://dmoz.org/Sports/Soccer.") 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="http://dmoz.org/Business/Industries/ 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="http://dmoz.org/Health/Addictions/Substance_Abuse/ Illegal_Drugs/" /> <rdf:value>Coke</rdf:value> </rdf:Description> </dc:subject> Example<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" > <channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0"> <title>Meerkat</title> <link>http://meerkat.oreillynet.com</link> <description>Meerkat: An Open Wire Service</description> <dc:publisher>The O'Reilly Network</dc:publisher> <dc:creator>Rael Dornfest (mailto:rael@oreilly.com)</dc:creator> <dc:rights>Copyright © 2000 O'Reilly & Associates, Inc.</dc:rights> <dc:date>2000-01-01T12:00+00:00</dc:date> <dc:type>Interactive Resource</dc:type> <image rdf:resource="http://meerkat.oreillynet.com/icons/meerkat-powered.jpg" /> <textinput rdf:resource="http://meerkat.oreillynet.com" /> <items> <rdf:Seq> <rdf:li resource="http://c.moreover.com/click/here.pl?r123" /> </rdf:Seq> </items> </channel> <image rdf:about="http://meerkat.oreillynet.com/icons/meerkat-powered.jpg"> <title>Meerkat Powered!</title> <url>http://meerkat.oreillynet.com/icons/meerkat-powered.jpg</url> <link>http://meerkat.oreillynet.com</link> <dc:creator> Rael Dornfest (mailto:rael@oreilly.com)</dc:creator> <dc:type>image</dc:type> </image> <textinput rdf:about="http://meerkat.oreillynet.com"> <title>Search Meerkat</title> <description>Search Meerkat's RSS Database...</description> <name>s</name> <link>http://meerkat.oreillynet.com/</link> </textinput> <item rdf:about="http://c.moreover.com/click/here.pl?r123"> <title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123</link> <dc:description>This the description of the article</dc:description> <dc:publisher>The O'Reilly Network</dc:publisher> <dc:creator>Simon St.Laurent (mailto:simonstl@simonstl.com)</dc:creator> <dc:rights>Copyright © 2000 O'Reilly & Associates, Inc.</dc:rights> <dc:subject>XML</dc:subject> </item> </rdf:RDF>
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. Namespacemod_DCTerms takes the namespace prefix dcterms: and is identified by the URI http://purl.org/dc/terms/. So, the root element looks like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dcterms="http://purl.org/dc/terms/" >ElementsYou 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.
Paired ElementsSome 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:
Using DCSV ValuesThere 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;
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." NamespaceThe events module takes the shapely ev: as its namespace prefix, and it is identified by the pleasingly regular http://purl.org/rss/1.0/modules/event/. So, the root element looks like this: <?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:ev="http://purl.org/rss/1.0/modules/event/" >ElementsThe mod_events elements are all subelements of item. None of them are mandatory, but common sense should prevail regarding usage: the more the better.
Example<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:ev="http://purl.org/rss/1.0/modules/event/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns="http://purl.org/rss/1.0/" > <channel rdf:about="http://events.oreilly.com/?_fl=rss1.0"> <title>O'Reilly Events</title> <link>http://events.oreilly.com/</link> <description>O'Reilly Events</description> <items> <rdf:Seq> <rdf:li resource="http://conferences.oreilly.com/p2p/" /> <rdf:li resource="http://www.oreilly.com/catalog/progxmlrpc/" /> </rdf:Seq> </items> </channel> <item rdf:about="http://conferences.oreilly.com/p2p/"> <title>The O'Reilly Peer-to-Peer and Web Services Conference</title> <link>http://conferences.oreilly.com/p2p/</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="http://www.oreilly.com/catalog/progxmlrpc/"> <title>Programming Web Services with XML-RPC</title> <link>http://www.oreilly.com/catalog/progxmlrpc/</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> </rdf:RDF>
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. NamespaceThe prefix for this module is the self-explanatory rss091:, and the module is represented by the URI http://purl.org/rss/1.0/modules/rss091#. Hence: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:rss091="http://purl.org/rss/1.0/modules/rss091/" >ElementsThe mod_rss091 elements represent the same elements within RSS 0.91. Chapter 4 provides details on those elements. Subelements of channel
Subelements of image
Subelement of item
Example<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:rss091="http://purl.org/rss/1.0/modules/rss091/" > <channel rdf:about="http://www.xml.com/xml/news.rss"> <title>XML.com</title> <link>http://xml.com/pub</link> <description> XML.com features a rich mix of information and services for the XML community. </description> <rss091:language>en-us</rss091:language> <rss091:rating>(PICS-1.1 "http://www.rsac.org/ratingsv01.html" l gen true comment "RSACi North America Server" for "http://www.rsac.org" 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>(mailto:webmaster@xml.com)</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="http://xml.com/universal/images/xml_tiny.gif"> <title>XML.com</title> <link>http://www.xml.com</link> <url>http://xml.com/universal/images/xml_tiny.gif</url> <rss091:width>88</rss091:width> <rss091:height>31</rss091:height> <rss091:description>XML.com...</rss091:description> </image> <item rdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html" position= "1"> <title>Processing Inclusions with XSLT</title> <link>http://xml.com/pub/2000/08/09/xslt/xslt.html</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> </rdf:RDF>
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. NamespaceThe mod_servicestatus prefix is ss:, and the module is identified by the URI http://purl.org/rss/1.0/modules/servicestatus/. So, a mod_servicestatus feed starts like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:ss="http://purl.org/rss/1.0/modules/servicestatus/" > ElementsThe first element of mod_servicestatus is a subelement of channel:
Example<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:ss="http://purl.org/rss/1.0/modules/servicestatus/" > <channel rdf:about="http://my.organisation.com"> <title>An Example</title> <description>Just an example of system statuses</description> <link>http://my.organisation.com</link> <ss:aboutStats>http://my.organisation.com/status.html</ss:aboutStats> <items> <rdf:Seq> <rdf:li resource="http://my.organisation.com/website" /> <rdf:li resource="http://my.organisation.com/database" /> </rdf:Seq> </items> </channel> <item rdf:about="http://my.organisation.com/website"> <title>Website</title> <link>http://my.organisation.com/website</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="http://my.organisation.com/database"> <title>Database server</title> <link>http://my.organisation.com/database</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 http://slashdot.org to see what's happening. NamespaceThe namespace prefix is slash:, and the identifying URI is http://purl.org/rss/1.0/modules/slash/. Hence: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > ElementsAll the mod_slash elements are subelements of item. They are all mandatory.
Example<item rdf:about="http://slashdot.org/article.pl?sid=02/07/01/164242"> <title>LotR Two Towers Trailer Online</title> <link>http://slashdot.org/article.pl?sid=02/07/01/164242</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. Namespacemod_streaming takes str: as its prefix, and http://hacks.benhammersley.com/rss/streaming/ is its identifying URI. So, its root element looks like this: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:str="http://hacks.benhammersley.com/rss/streaming/" > ElementsAll 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.
Example<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:str="http://hacks.benhammersley.com/rss/streaming/" > <channel rdf:about="http://www.streamsRus.com/"> <title>Streams R Us</title> <link>http://www.streamsRus.com</link> <description>Streams R Us: An Entirely Fictional Site</description> <str:type>both</str:type> <image rdf:resource="http://www.streamsRus.com/icons/stream.jpg" /> <items> <rdf:Seq> <rdf:li rdf:resource="http://www.streamsRus.com/example.ram" /> <rdf:li rdf:resource="http://www.streamsRus.com/example2.mp3" /> <rdf:li rdf:resource="http://www.streamsRus.com/example3.mov" /> </rdf:Seq> </items> </channel> <item rdf:about="http://www.streamsRus.com/example.ram"> <title>RSS Rocks Out</title> <link>http://www.streamsRus.com/example.ram</link> <str:associatedApplication>realplayer</str:associatedApplication> <str:associatedApplication.downloadUri>http://www.real.com/ </str:associatedApplication.downloadUri> <str:duration>00:04:30</str:duration> <str:live>recorded</str:live> </item> <item rdf:about="http://www.streamsRus.com/example2.ram"> <title>RSS Rocks Out Live</title> <link>http://www.streamsRus.com/example2.mp3</link> <str:associatedApplication>winamp</str:associatedApplication> <str:associatedApplication.downloadUri>http://www.winamp.com/ </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="http://www.streamsRus.com/example3.mov"> <title>RSS Rocks Out Live on Video</title> <link>http://www.streamsRus.com/example2.mov</link> <str:type>video</str:type> <str:codec>sorenson</str:codec> <str:associatedApplication>Quicktime</str:associatedApplication> <str:associatedApplication.downloadUri>http://www.apple.com/quicktime </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>mailto:ben@benhammersley.com</str:live.contact.Uri> </item> </rdf:RDF>
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. Namespacemod_syndication takes sy: as its prefix and http://purl.org/rss/1.0/modules/syndication as its identifying URI. Thus: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" > ElementsThe mod_syndication elements are all subelements of channel:
Example<channel rdf:about="http://meerkat.oreillynet.com/?_fl=rss1.0"> <title>Meerkat</title> <link>http://meerkat.oreillynet.com</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 http://www.dmoz.org, is a good source of taxonomic URIs. All the examples in this section originate from this source. Namespacemod_taxonomy takes the stylish moniker of taxo: and the identifying URI of http://purl.org/rss/1.0/modules/taxonomy/. Hence, the lovely root element: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" >Elementsmod_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. Example<item rdf:about="http://c.moreover.com/click/here.pl?r123" position="1"> <title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123</link> <description> XML is placing increasingly heavy loads on the existing technical infrastructure of the Internet. </description> <taxo:topics> <rdf:Bag> <rdf:li resource="http://meerkat.oreillynet.com/?c=cat23"> <rdf:li resource="http://meerkat.oreillynet.com/?c=47"> <rdf:li resource="http://dmoz.org/Computers/Data_Formats/Markup_Languages/XML/"> </rdf:Bag> </taxo:topics> </item> <taxo:topic rdf:about="http://meerkat.oreillynet.com/?c=cat23"> <taxo:link>http://meerkat.oreillynet.com/?c=cat23</taxo:link> <dc:title>Data: XML</taxo:title> <dc:description>A Meerkat channel</dc:description> </taxo:topic> <taxo:topic rdf:about="http://dmoz.org/Computers/Data_Formats/Markup_Languages/XML/"> <taxo:link>http://dmoz.org/Computers/Data_Formats/Markup_Languages/XML/</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="http://meerkat.oreillynet.com/?c=cat23"> <rdf:li resource="http://dmoz.org/Computers/Data_Formats/Markup_Languages/SGML/"> <rdf:li resource="http://dmoz.org/Computers/Programming/Internet/"> </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 (http://www.threadsml.org/). 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. Namespacemod_threading takes the prefix thr: and the identifying URI http://purl.org/rss/1.0/modules/threading/. Hence, the root element: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:thr="http://purl.org/rss/1.0/modules/threading/" > ElementThere'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. Example<item rdf:about="http://c.moreover.com/click/here.pl?r123"> <title>XML: A Disruptive Technology</title> <link>http://c.moreover.com/click/here.pl?r123</link> <thr:children> <rdf:Seq> <rdf:li rdf:resource="http://www.example.com/child1"/> <rdf:li rdf:resource="http://www.example.com/child2"/> <rdf:li rdf:resource="http://www.example.com/child2"/> </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. Namespacemod_wiki's prefix is wiki:, and the identifying URI is http://purl.org/rss/1.0/modules/wiki/. mod_wiki also uses mod_dublincore for some of its elements. Hence, the lovely root element: <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:wiki="http://purl.org/rss/1.0/modules/wiki/" > Elements
Example<item rdf:about="http://www.usemod.com/cgi-bin/mb2. pl?action=browse&id=JohnKellden&revision=30"> <title>JohnKellden</title> <link>http://www.usemod.com/cgi-bin/mb2.pl?JohnKellden</link> <description></description> <dc:date>2002-07-03T06:47:19+00:00</dc:date> <dc:contributor> <rdf:Description wiki:host="pc88-86.norrkoping.se" > <rdf:value>pc88-86.norrkoping.se</rdf:value> </rdf:Description> </dc:contributor> <wiki:status>updated</wiki:status> <wiki:importance>major</wiki:importance> <wiki:diff>http://www.usemod.com/cgi-bin/mb2. pl?action=browse&diff=4&id=JohnKellden</wiki:diff> <wiki:version>30</wiki:version> <wiki:history>http://www.usemod.com/cgi-bin/mb2.pl?action=history&id=JohnKellden</ wiki:history> </item>
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. Namespacemod_prism is identified by the prefix prism: and the URI http://prismstandard.org/namespaces/1.2/basic/. 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="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/" >ElementsThe 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.
ExampleThis 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="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns="http://purl.org/rss/1.0/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/" > <channel rdf:about="http://www.nature.com/nature/journal/v432/n7013/rss.rdf"> <title>Nature</title> <description>International weekly journal of science</description> <link>http://www.nature.com/nature/journal/v432/n7013/rss.rdf</link> <rdfs:seeAlso rdf:resource="http://www.nature.com/nature/journal/v431/ 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>permissions@nature.com</prism:rightsAgent> <image rdf:resource="http://nurture.nature.com/rss/images/nature_rss_logo.gif"/> <items> <rdf:Seq> <rdf:li rdf:resource="http://dx.doi.org/10.1038/432004a"/> </rdf:Seq> </items> </channel> <image rdf:about="http://nurture.nature.com/rss/images/nature_rss_logo.gif"> <title>Nature</title> <url>http://nurture.nature.com/rss/images/nature_rss_logo.gif</url> <link>http://www.nature.com/nature/</link> </image> <item rdf:about="http://dx.doi.org/10.1038/432004a"> <title>Climate change clouds commercial licence to krill</title> <link>http://dx.doi.org/10.1038/432004a</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> </rdf:RDF> |
EAN: 2147483647
Pages: 118