作者:傲气战歌网 来源:www.27zg.com 发表时间:2014-03-14 02:02
In the RDF Schema snippet above, it also says that the title property is a subproperty of the resource , an element defined by the Dublin Core Metadata Initiative. We can then infer from these statements that the literal "The Joy of Blogs" is also related to the item as a Dublin Core title. If, for example, a browser-like application were reading the data, but didn't know how to render rss:title, it could reasonably substitute the renderer for dc:title.
What do we gain from all this formal grounding? If RSS processing alone is our universe, maybe not a lot. But as soon as we want to start integrating our RSS with other RDF data, or merge other data into our RSS, we start to reap rewards.
Extending RSS: Software ReleasesAs an example of extending RSS, we'll take a software company's product announcement RSS feed. Periodically they release updates to their product, and they would like the announcement of the update to be an automated part of the release process. So when a new release build is made, an item will be inserted into their news feed that contains the product name and the release version.
We create an RSS module by defining the properties we need, explaining their usage and associating them with a unique namespace. On the face of it, this is a trivial exercise -- for the update module we can just define a couple of simple elements:
product - the name of the product. A character string.
version - the version of the release expressed as a string in the format x.y where x is the major version number and y the minor version number.
For a namespace we just need a URI, ideally one under our control. So if we have registered the domain name supersemantics.com then we could use that as a base. It's a good idea to recommend a prefix to use for the namespace within XML documents, and here we shall use rel.
Here's what this might look like in our RSS 1.0 feed.
xmlns:rel="http://supersemantics.com/ns/release/" ... <item rdf:about="http://supersemantics.com/release/2003/06/19#9"> <title>New Release</title> <dc:date>2003-06-19T14:02:33+01:00</dc:date> <rel:product>IronBoard</rel:product> <rel:version>2.3</rel:version> ...The date in RSS 1.0 is expressed using a W3C Date Time Format DTF (W3CDTF), a profile of the ISO 8601 standard.
By using the RDF document the syntax here we actually says more than we would with plain XML. The product and version elements are actually RDF properties, relating the item resource to literal strings. There are two statements being made here which can be expressed as subject (what's being described), predicate (the property), and object (value of that property):
#9 rel:product
"IronBoard"
#9 rel:version
"2.3"
The (subject, predicate, object) statement is an important concept in the RDF world and is usually referred to RSS 1.0 RDF Schema as a triple. The subject of one triple may be the object of another and vice versa. This means the triples can also be thought of as a joined-up structure, and that structure is the RDF graph.
So what's the big deal? The relationship between the item and the product name and version number is already defined. We can load our RSS file into any RDF aware toolkit (and there are plenty, see Dave Beckett's Resource Guide) and have it immediately know that an item has properties product and version. We don't need any more programmer logic to extend the data model.
If we wish to offer our new module for reuse by others we can, in the same way that the item and title properties are defined in the RSS 1.0 RDF Schema, provide a schema with formal definitions for our terms.
Working with Existing VocabulariesWe noted earlier that the RSS 1.0 title property was actually a subproperty of Dublin Core's title. Some parts of the RSS 1.0 vocabulary such as dc:date and dc:creator are used directly from Dublin Core. Generally speaking it's good practice to use existing vocabularies directly wherever possible, as it's the best route to interoperability. A common scenario is that a general purpose vocabulary contains a term close to what we're looking for, but our requirement is more specific. The solution here is to define our own term as a subclass or subproperty of the existing term (depending whether the term applies to an entity or a relationship between entities). Thus the child class (or property) takes on the same characteristics as its parent, in addition to anything specific to the child.