Danny, the killer app for HTML was Mosaic.
Dan Brickley • 8/6/03; 5:13:15 PM

ps. yes, there are two titles because one is the title of a Web document, the other is a job title. To confuse matters, these often contain very similar words.
Dan Brickley • 8/6/03; 1:06:29 PM

I'm very glad to see this dialog happening! I don't have time to write much today, hope to respond to Jon's piece tommorrow. In brief, please don't beat him up for bugs in the rough'n'ready RSS1+jobs example markup, it was taken from a piece Libby Miller and I wrote some years ago, http://ilrt.org/discovery/2000/11/rss-query/

What we were trying to do there was make about about RSS and RDF/namespaces as a general purpose transport for data about all sorts of things that weren't intrinsically connected with RSS at all, except via being described in RSS feeds. If you think of this in entity/relationship modeling terms, OO or [choose your tech religion...], and consider the kinds of things (and relationships, attributes etc.) being described using extension namespaces, they're totally varied. People, Places, Organisations, Photos, Audio Files, Movies, Bank Accounts, Jobs, Chat Rooms. It's completely unpredictable. The scope is as broad as the uses to which the Web itself is being put.

What our old RSS/jobs markup tried to do was make something explicit that is easily glossed over. Jobs and job description Web pages are different entities. The basic structure of RSS is good for dealing with documents and their descriptions, titles, dates etc., but doesn't really address the deeper need to describe the thing that the document is *about*. In this case, each document is about a job. Jobs have salaries, locations, etc; documents have size-in-bytes. RDF imposes a classes and properties discipline familiar from OO (but with interesting differences), and so helps us to be more explicit in distinguishing characterstics of the Job from characteristics of the page about the Job. But it doesn't force us to make such distinctions. So while I'm an RDF advocate, RDF alone doesn't force us to model things well. It does help us to make explicit the implicit models that sit behind our markup, though. And in a loosly-coupled environment where data producers and consumers don't share much context, explictness is good. (see also endless REST vs RPC debates in Web Service world for similar concerns)

Aside: why did I use the Wordnet namespace? Partly just to show that I could freely mix in another ns. It would have also been quite reasonable to have the Jobs namespace declare a class 'Job' and in the Jobs schema declare that class to be subclass of wordnet:Job. But I wanted to show namespace mixing in instance data, so I did. Wordnet btw is pretty cool, I made it into a 50,000 class RDF schema http://xmlns.com/2001/08/wordnet/, which contains most terms from everyday English. And it beats having a committee argue about selecting which words go into the schema -- just put them all in ;-)

So one lesson I took from http://ilrt.org/discovery/2000/11/rss-query/ was that it really shows how RSS should melt into the background for many data-oriented apps. If you look at the queries we were doing, they're all matches against stuff from the extension namespaces, ie. the client app is asking about the characteristics of the thing described in the RSS-syndicated document, and not about the document. RSS was just the transport; the RSS markup itself was discarded. We care about the Job itself not the job-description Web page it's associated with. The page is a means to an end (employment!).

Anyway I'm pleased that old writeup is getting some attention. Since then I wrote a few other things (in ESW wiki) in a similar vein which stress the ability to distinguish (or fail to distinguish) things from their descriptions. For eg., people, restaurants etc. This imho is the core *modeling* problem we're facing with RSS+namespaces. A bunch of the early RSS1 namespace extension modules didn't really get this right, and ascribed to a document characteristics of the thing the document describes.

Further notes on this and related topics in the ESW Wiki at W3C:

http://esw.w3.org/topic/PersonsVersusTheirDescriptions http://esw.w3.org/topic/RestaurantsVersusTheirReviews

The restaurant case is probably most interesting, and comes with some nice datasets / examples, from Chef Moz and Wiki-based review systems, more details at http://esw.w3.org/topic/RestaurantRecommendation
Dan Brickley • 8/6/03; 1:05:05 PM

 re. the RDF killer app : there is no killer app

Put it another way - what's the killer app for html? Internet Explorer? The killer app is an improved web. (Sorry, I couldn't find the link for comments for today's post, but it's still reasonably on-topic ;-)
Danny • 8/6/03; 12:29:35 PM

 Some misreading of Dan's original comment I believe.

RDF is a model, a rigorously tested and defined model that allows one to create vocabularies that not only record data, they also allow us to infer new knowledge from existing data. RDF/XML is a serialization format for this, requiring that certain constraints and criteria be included within the XML document to ensure that the requirements of the model are met. Some people aren't happy about this, but this is life.

However, based on these constraints and criteria, it's an extremly simple matter to combine elements from multiple RDF-based vocabularies together using namespaces, as I believe Dan mentioned. Since this same rigor isn't present in vanilla XML, such as RSS 2.0, then you have to work through the issues, as I believe Dan also mentioned.

At no point did Dan mention that you can throw RDF and plain-vanilla XML together and have it 'work'. Unless I missing something in the comments.
Shelley • 8/6/03; 10:21:11 AM

 I agree with Alf, above (http://www.pmbrowser.info/hublog/archives/000430.html ). This is the way to do it. RSS is the transport and the jobs-related RDF is the payload. This allows any-old RSS feed reader to display something useful. Extended, jobs-aware systems can do more with the rich data. Because RSS 2.0 is namespace tolerant, all of the XML lives together, nicely, in a single "document". I have no public-facing examples, but we (http://www.tpt.com) do this all the time with our internal RSS 2.0 feeds: carry "extra" data within namespace-delimited tags so that the same RSS document can serve both the off-the-shelf feed reader as well as appliation-specific systems.

Of course, all of this requires that the RSS feed reader and jobs-aware system "do the right thing" vis-a-vis their handling of the XML. I've noticed an unfortunate trend among XML-aware applications to fall over when they don't get the XML they expect. Extra tags are fine and should be silently ignored. The RSS feed reader ignores the RDF. The jobs system ignores the RSS.

This assumes, however, you use Alf's suggestion, above.

Your mock-up is neither fish nor fowl, and likely requires both RSS and jobs/RDF-handling systems to change, which is exactly what you don't want.

I am not and RDF expert, but I'm surprised to hear Dan's comments (not here, rather here - http://blogs.law.harvard.edu/tech/discuss/...ader$167?mode=topic - I think) indicating that he's only hopeful the RDF/XML side should/will work. I understand that XML is only one way to render RDF. It just seems to me that an RDF-aware system that can NOT handle non-RDF bits in its XML stream is completely missing the point of XML. Use and understand RDF if you want, but don't force everyone else to.
Allie Rogers, Jr. • 8/6/03; 6:50:56 AM

 I would have preferred using 'jobs' as an RSS extension, unless there's a real reason for the RDF. Like this perhaps?: http://www.pmbrowser.info/hublog/archives/000430.html
Alf • 8/6/03; 1:57:44 AM

 What about embedding your rdf stuff inside the "description" tag of the RSS? Excuse my ignorance if I'm missing something.
alsanan • 8/6/03; 12:37:05 AM

 i'm working on implementing RSS/RDF feeds on my free and open source job feeds site (that jon somehow missed). i'll be monitoring comments here, and including suggested changes and additions. of course, this will be entirely useless unless someone implements the other end.
scott reynen • 8/5/03; 3:28:13 PM

 your rss tag ends (>) before the namespaces (as well as after).
scott reynen • 8/5/03; 2:48:31 PM

 Kellan writes:

"are you trying to make the whole file valid RDF, or just pieces of it?

Also, what is the WordNet namespace doing in there? Is that another RDF namespace? It add a complexity to your example which didn't seem to help it much."

Kellan: I'm not trying to make the whole file valid RDF. It is an RSS 2.0 feed. The question is whether the feed can usefully contain RDF, and if so how.

Regarding WordNet, that's also simply cribbed from Dan Brickley's RSS 1.0 module.
Jon Udell • 8/5/03; 12:53:49 PM

The reason one seperates about from link is that the about element has to be unique per feed, while the link element does not. However, whether you need it seems tied to Sjeord's 2nd question, are you trying to make the whole file valid RDF, or just pieces of it?

Also, what is the WordNet namespace doing in there? Is that another RDF namespace? It add a complexity to your example which didn't seem to help it much.
kellan • 8/5/03; 12:48:09 PM

 I am confused. Are you trying to make the whole file valid RDF?
Sjoerd Visscher • 8/5/03; 12:16:24 PM

 Sjoerd writes:

"The items element can better be removed. The only real information it provides is that the items have a particular order. The order of items is clearly not relevant here.

I'm also puzzled by the about elements. How are they any better than the link elements?"

Sjoerd: Some regard the extra item enumeration in RSS 1.0 as unnecessary. Likewise the about elements (which are attributes in RSS 1.0, but which I made elements here just to make the validator happy). For the purposes of this example, I'm going to assume that from an RDF perspective these things are necessary, and am simply trying to figure out whether RSS 2.0 and RDF can be woven together in a way that is acceptable to all stakeholders.
Jon Udell • 8/5/03; 11:40:08 AM

 Michael:

Dunno, I'm just making this up as I go along :-) Seriously, that apparent duplication was simply cribbed from Dan Brickley's example. Perhaps the difference is that rss:title is the title of the item (e.g. "Senior Engineer wanted, Toledo OH area") whereas job:title is something like "Senior Engineer".

The point of this exercise, for me, is to come up with a working example of how application-specific data can be included in an RSS feed -- the RDF aspect being, in my mind, just one way to do that. Then, to see what happens when you smash namespace-qualified vocabularies together, and to try to understand what are best practices for doing that usefully and sanely.
Jon Udell • 8/5/03; 11:36:27 AM

The items element can better be removed. The only real information it provides is that the items have a particular order. The order of items is clearly not relevant here.

I'm also puzzled byt the about elements. How are they any better than the link elements?
Sjoerd Visscher • 8/5/03; 11:23:31 AM