Bb, thanks.

I've posted a follow-up on my weblog (see http://radio.weblogs.com/0106548/2002/09/11.html#a81).

I actually think vanilla XML has more expressive power than you're giving it credit for, Bb. Thing is, that power derives from ambiguity. Friend of mine, a philosopher type, is currently engaged on a research agenda that asks what people *mean* when they mark stuff up. Turns out to be a surprisingly difficult question.

Which is not to say that disambiguation is a bad thing, of course.

Bb, your writing is always clear and this makes me look forward to your RDF book even more.

I do agree with Ziv's obervations about the advantages of out-of-band data and how RDF doesn't operate that way. I think it would have been better if RDF operated more like CSS, but then again we all know what a CSS bigot I am. :)
This does make me think that Sjoerd's tactic may be more generally applicable than to just RSS feeds:
http://w3future.com/weblog/2002/09/09.html#a129

I thought his idea was a good stop gap until more RDF tools were available, but now I think it could be a long term technique. The advantage of the idea can be seen in three cases.

1. I could define a simple blogger-info-format in XML that contains information about the person, their favorite books, and all their cats info too. Now you can process this XML file with different XSL transformations to get different RDF files, one for FOAF, one for a book list, and a third for the cats. Now if an RDF vocabulary for the cats doesn't exists you still have that info and can just add the XSLT later when the CDT (Cat Description Taxonomy) is complete :).
You can also apply an XSL transform to turn that XML file into HTML. Note that in all these cases the transformation is from general XML to a restricted subset of XML.

2. Since I am producing valid XHTML on my site I don't actually need to produce a separate RSS file, I can just have an XSLT file that transforms my main page into RDF, say RSS 1.0.

3. Say the RSS 1.0 group made a wee little mistake and their format ends up not being valid RDF, or say it doesn't quite mean what they intended when consumed by pure RDF tools. If the RDF were produced through a transformation then fixing the error would only be a matter of updating that XSLT file, while today it would be a large effort distributed across all the tools that generate RSS 1.0. (ok, maybe that was a vast oversimplification, but updating *would* still be easier using XSLT.)

I like RDF. I like the promise of RDF. RDF that worked like CSS would be better. RDF via XSLT comes real close.

For more on RDF-scraping, see .

Plenty of good links. More ways to do this than XSLT.

Well, that was pointless. Try this instead: http://www.ldodds.com/wordtin/Wiki.jsp?page=RDFDataMining.

FYI, it has been proven that the "typos" in Ulysses were deliberately incorporated into the text by Joyce. A scholar at my university located the original galleys and proved that in many cases, Joyce liked the errors made by the typesetters and actually altered the text to work them into the text more skillfully.

The downside to using a one-size fits all approach of an XHTML web page and XSLT is the extra work it entails. Not every environment is going to have XSLT available; server or client side. Not to mention asking the various content management environments to rise up to the exacting level of standards demanded by XHTML isn't a trivial issue. Just getting folks to make compliant RSS feeds has been an adventure. Getting them to make compliant XHTML and correct XSLT, while an admirable goal, is extremely unlikely within the next 24 months; if ever.

In addition it's very likely that the content delivered into the RSS feed may well benefit from being different than that of the website itself. Used as a draw from RSS to the website, for example, would benefit from a different set of links or even variations in the text.

There's a tendency to oversimplify. When quite often that level of simplification greatly increases the complexity elsewhere in the production cycle. TANSTAAFL, as the saying goes.

So we have a chance to focus on using something like an RSS-1.0 feed to gauge just how much work it's going to take. Should a site be able to produce and perceive value from an RSS-1.0 feed then making greater strides to integrate into their HTML site might be a worthwhile endeavor.

Bill,I would more like to hear your opinion on #3, that is keeping the simpler RSS 2.0 format and using an XSLT sheet defined and maintained by an RDF expert.

The discussion about #3 is interesting. The existing RSS-1.0 docs have been commented on as having been incorrect and difficult to read. This is being rectified. There have also been discussions about how to correctly structure the data so that is can be as RDF-friendly as possible while not be overly complicated. This question is being addressed by some of the more RDF-savvy folks like Shelley and Dan Brickley. Stay tuned for more details from them.

But to cut to the chase, if you're going to bother creating a feed you might as well create a well constructed one. Why bother creating one in format A only to transmogrify it into format B? When format B is readily consumable by the majoroty of tools currently shipping? Not to mention, what if format A doesn't have support for something usable in format B? You'd have to 'fake it' in your transformation. Why not take it from the other angle, produce the data in Format B (RSS-1.0) and then use a transform to strip it of meaningful structure and push it out as 0.94?

What appears to be happening is that more and more people are becoming aware of a much wider range of applications. This is a good thing. Surprisingly the RSS-1.0 format, now two years old, has always been capable of handling this sort of stuff. What has been missing is discussion, documentation and understanding. It appears we're finally getting to those points.

If you think it's been hard enough getting people to use 1.0 instead of .9x, then the trip from static files to XSLT is going to be even harder.

"But to cut to the chase, if you're going to bother creating a feed you might as well create a well constructed one. Why bother creating one in format A only to transmogrify it into format B?"

Because A is more complicated and harder to 'get right' than B. That is why it is hard to get poeple to use 1.0 instead of .9x.

"If you think it's been hard enough getting people to use 1.0 instead of .9x, then the trip from static files to XSLT is going to be even harder."

Note that I was careful to say: "an XSLT sheet defined and maintained by an RDF expert." And this step, the XSLT transformation, would only be necessary for people that want to get the 'benefit' of providing RDF.
But what benefit is there? What actual, real-life, right now benefit do I get by providing RDF? None. RSS 2.0 provides me a benefit because I can use namespaces and modules to safely add extra information into my feed.

"Surprisingly the RSS-1.0 format, now two years old, has always been capable of handling this sort of stuff."

Yes, because it supports namespaces, not because it is RDF.

First off, the assumption of an RDF/XSLT expert being available and willing to do this is a bit of a stretch. I've worked in XSLT and it's not for the faint of heart. Given the desire of many people to customize their templates I don't see them making use of XSLT without a LOT of headaches. Many more than just using RSS-1.0.

I'm puzzled by how many people have bought into the fantasy of RSS-1.0 somehow being 'more complicated' than 0.9x. Just using XML properly is more complicated than plain text; we see plenty of hassles with people just grasping character encoding properly. All RSS-1.0 requires above 0.9x is the use of a Seq list. Otherwise it's structure is nearly identical to 0.9x. If you want to make use of some modules you're faced with using their structures. But at least you're faced with the choice of doing so, 0.9x doesn't support them at all. So in this case you're correct in the oversimplification that 1.0's support of namespaces is the key; it's but one part of it.

As Shelley has offered, using RDF structures can allow something more intelligent to be determined from it's use in a feed. I'm not going to reiterate those points here as she does a much better job than I.

As for 'real life' benefits, well if you don't provide data and don't use RDF tools you're certainly not going to get the benefits. But if you do want to be able to make larger associations or cross-references against the data you'd have a tougher time doing it without a framework like RDF. There's a whole world of tools out there for using RDF, to be unfamiliar with them is one thing, to rail against what you don't understand is a whole other mistake.

As for the pseudo-2.0 standard, there's nothing any safer about using a format defined by a vendor that doesn't understand frameworks than it is to use a framework that 'you' don't understand. Using the framework means as you come to understand the value of it you'll be able to reap the benefits. Not using any sort of framework means you're shit out of luck; forced to use much cruder efforts. To put it mildly, if you use a crappy format nobody but that vendor will be able to make sense of it. If you use an internationally recognized format you'll be able to have it's international audience and their tools to utilize.

What would you rather follow, a short-sighted format proclaiming nothing more than simplicity (with no future) or a robust framework with significant research behind it?

"I'm puzzled by how many people have bought into the fantasy of RSS-1.0 somehow being 'more complicated' than 0.9x."

It *is* a more complicated format. Trying to de-legitimize the complaint by labelling it a 'fantasy' is unproductive.
Maybe you can talk to some of the members of your own working group who also think
that RDF adds unnecessary complexity: http://weblogs.userland.com/eclectic/2002/09/10 http://www.raelity.org/archives/2002/09/05#computers/data/rss/rss_flowers

"There's a whole world of tools out there for using RDF,"

Please provide a single concrete benefit for having RDF in RSS.
Please provide a single concrete benefit that isn't just a function of using namespaces.

A single concrete benefit. That's all I'm asking for.

"What would you rather follow, a short-sighted format proclaiming nothing more
than simplicity (with no future) or a robust framework with significant research behind it?"

Would I rather use RSS 1.0 or 2.0? I would rather use neither. I would like to use a
differently named format that has the simplicity of .9x while still 'enabling' RDF.
Note I said 'enabling' and not 'baked right in.'
I would also like that format to benefit from all the module building experience of rss-dev.
This is an idea even Dave Winer can accept: http://scriptingnews.userland.com/stories/storyReader$1744#theSoapOfSyndication

Unfortunately rss-dev has repeatedly rebuffed such suggestions.

rss-dev has had it's share of issues with people feeling rebuffed. In the last month's elected several new members to it's working group. All of which a 'new school' type of developers not steeped in RDF or other academic traditions. As a result there's been a lot of new traffic on the list. Much of which surrounds correcting the ambiguities in the spec.

The only downside to using RDF is simply grasping a few core concepts like using an rdf:Seq, when to use rdf:About vs rdf:Resource and the like. The other stuff is largely not needed in RSS and can well be avoided. But the docs are not clear on this and that IS being rectified.

As for concrete benefits look into graphviz, isaviz, RDFquery, Jena, Redland, DAML/OIL and a whole host of other major projects producing and consuming RDF. It's out there. Do you have a large pool of RSS XML you want to search? If not then you probably don't care a whit about RDF. Some folks, however, do desire being able to perform sophisticated searches against their XML data. Using RDF brings along a wealth of powerful tools that aid that process.

The modules as constructed are based on RDF. Using them and their namespaces brings along RDF.

What Rael (to whom I have spoken with at length about his) and Eclectic have offered is that the use of the RDF framework hasn't made it's value clear. That is being addressed. Will it be addressed 'in time' to stave off yet another version-arms-race-with-RSS, probably not. But will anything already using RSS-1.0 stop doing so? Unlikely. Will anything not automatically upgraded by the vendor start producing pseudo-2.0? Also unlikely save for one or two reaggregators.

What continues to be deeply troubling about all this is the failure to follow history. The back-story behind all this isn't apparent. There's this sentiment trying to spun that pseudo-2.0 is somehow better for folks. It's not; it's largely just cherry picking (and poorly at that) what's already been possible in 1.0. All the while trying to put some incredible spin on it.

The question is perhaps reflected in this sentiment; are you in a hurry to use something new that doesn't base itself on any sort of well-considered research? Or would you rather learn why so many people have put countless hours into crafting a well-formed framework?

To base efforts on little more than svengali-like charisma and personality cult doesn't seem very insightful. But hey, people have made that mistake before and will doubtlessly do it again.

svengali = "A person who, with evil intent, tries to persuade another to do what is desired."

Bill you sling the mud around so freely, your case must be very weak indeed if you have to impugn my reputation at such a personal level, to make it.

Bb, thank you for the clearest description of the value and theory of predicate logic I've ever read. The illustration via RDF is a great bonus.

If I hadn't read your posting, it never would have occured to me that Lojban (a predicate logic based constructed language) or other similar conlangs could be expressed as RDF, (thus continuing the knowledge graph down into the RSS feed content)

I wonder if use of RDF will lead to more interest in predicate logic based conlangs such as Lojban.

where you be, shelley p?

"fantasy", "svengali-like", and "personality cult" are all unproductive.

"As for concrete benefits look into graphviz, isaviz, RDFquery, Jena,
Redland, DAML/OIL and a whole host of other major projects producing
and consuming RDF."

That is, if I am not mistaken, a list of tools for manipulating RDF.

For the third time I will ask,
please provide a single concrete benefit for having RDF in RSS.
Please provide a single concrete benefit that isn't just a function of using namespaces.

A single concrete benefit. That's all I'm asking for.

For example, you have that collection of powerful tools for manipulating RDF
that you just listed.
You also have a big pile of RDF, ie. over 1300 RSS 1.0 feeds[1], plus
some 40 odd deployed FOAF files[2]. With those powerful RDF tools
and that big pile of RDF shouldn't it be *easy* for you to put
together a compelling example of the value of RDF in RSS?

[1] http://www.syndic8.com/stats.php?Section=feeds#RSSVersion
[2] http://rdfweb.org/rweb/wiki/wiki.pl?FOAFBulletinBoard

I have two reasons for RDF in RSS:

1. It is an excellent way to get RDF in common use.
2. RDF is a good method of storage and retrieval of large amounts of data, which keeping it simple, and related.

RSS is an excellent type of dta for RDF-ification.

However, I don't think that it is necessary to have it, and it *DOES* add a level of complexity.

As an aside, I'm NOT an RDF expert, but I can write RDF, and I am quite handy with XSLT, and would be quite willing and up to the task of managing a converter to RDF.

Well, to quote Dave I'll just point back to this own text: "Anyone who works with Hemenway or Kearney should be aware that these people are nothing less than monsters, who will stoop to any level to get their way."

A concrete benefit to the framework is the use of schemata. Let's say you create an element called "releaseDate" in a namespace called "joe". So now you have the element:

<joe:releaseDate>2002-09-16</joe:releaseDate>

Now, unless someone takes the time to investigate what you're doing they're never going to be able to have their programs recognize that what you're doing is date-related. That is, not unless you make use of a framework and a schema or they hardcode their application to use your special elements.

There have been tremendous efforts put forth by the W3C and others to try and stablize some concepts. The Dublin Core effort has attempted to put forth a set of descriptions about what an element can be understood to mean. In other words, the semantics of things. (I shudder when I see terms like semantics, taxonomies, normative and the like, but they DO help explain stuff.) One could argue that it's worthwhile to learn from those efforts and use their element descriptions. It's not easy to do the research necessary to discover that dc:date isn't as effective as using dcterms:modified. The docs on this stuff have really made it much harder to grasp than I'd like. But I didn't write 'em so there's not a lot I can do about that.

What using a namespaced element from a framework will do for you is to let any other tools that handle the XML data to correctly handle your data. They come across stuff with date properties and they can do all the things such an element needs; converting to local time from UTC, sorting, indexing and the like. It sounds trivial but in a programmatic environment those little ambiguities mean endless amounts of extra error checking code. If you use agreed meaning (semantics) for an element you narrow down the steps needed to handle it properly. So using a namespace will help.

Ok, so using an element from another namespace might well be a good idea. How does that matter in regard to RDF? Let's say you can't use the element as named from that namespace. A point-haired-boss says you HAVE to call it <somecorp:releaseDate/>. How are you going to expect people consuming it to understand that it's really just dcterms:modified? You'd need to use a framework of some kind. One avenue is to use the sort of schema that RDF follows. It's not perfect, by any stretch, but it does have some nice features.

What you could do in your schema is make an association from your locally named element to that of the dcterms namespace. The advantage here is anything trolling through the XML can discover that your unknown element is really just a date and can be handled as such.

This is the sort of reason using a framework has value. It's not just the applications you know about *today* you need be concerned about. It's the applications that will come along in the future or from unexpected circles that benefit from being able to 'make sense' of what your data represents.

Now, does that answer the question of why RDF? It might not as one could make arguments about using any number of different schema ideas. A benefit of RDF concept is you've got a whole team of people working it. Sure, they've had their share of complications and their documentation seriously confuses people. But there's significant value in the "they" of the effort. Instead of just one developer chanting some mantra of pseduo-simplicity you get a legion of some of the smartest minds on the Internet.

So my perception of using RDF is that for the price of some small syntactic mumbo-jumbo you get to ride along with some really amazing development being done elsewhere.

RDF doesn't really have much fo anything to do with XML.

RDF is a conceptual way to store related information... XML just happens to be a way to serialize it so that it is useable. RDF could also be serialized in other manners.

I think the real question is why should the concept of RDF be applied to RSS? That concept being the use of subject/predicate/resource to store all data. Why does this apply to RSS better than, say, simply storing the data?

You raise a valid point. What's the harm in just inventing some new element names and leaving it at that? There's no 'harm' per-se. The data remains just the data. The disadvantage is that there's nothing about the data that helps explain itself. Using subj/pred/rsrc allows for a little bit more meaning without significant overhead. Really, are we just trying to argue over a few bytes here? If so, using XML ain't a good idea at all but let's not open that can of worms (as in N3). The value behind applying RDF concepts to RSS rests on being able to make use of it's structure in ways that move RSS into much more complex scenarios. Rather than reinvent the wheel as needs grow in RSS, why not take advantage of some seriously brilliant work being done in things like the RDF efforts? The kind of brilliance that keeps you from describing the data in ways that don't have sound design principles.

Perhaps another analogy here is that of database design. Some folks might try to argue there's no need to bother crafting a well-formed database schema, that it's best to just tack on fields and tables as needs are discovered. Fortunately years of database design research indicates the folly of such thinking. Proceeding with some core design concepts allows for much more predictable growth, if not avoiding outright dead ends and road blocks.

So my thinking here is that if you follow along with what's being considered for where RDF is going you'll see plenty of places RSS would be a perfect fit. And if said RSS is already using RDF features, those environments will be able to interact with the data with little or no extra effort.

The alternative is you cobble up something overly simplistic and, as a result, force any other tools to try to work around the poorly thought through design.

Bill said: "Really, are we just trying to argue over a few bytes here? If so, using XML ain't a good idea at all but let's not open that can of worms (as in N3)."

No, the number of bytes is of no concern. It's the *contents* of the bytes that makes the difference. My (and I think Joe's) problem is not with RDF-the-concept at all. It is with the RDF-to-XML serialization format. Why is it that I can use an RDF Schema to say " is the same as ", but I cannot say "when is a child of , that is a resource"?

As I said in my response (linked by the first post above), I have no quarrel with RDF, and if RDF parsers and tools were better available (and more widely deployed), I wouldn't have a problem with its serialization format. But *currently* we deploy applications that work at the XML level, and at that level we simply cannot handle a general-purpose RDF document -- it must follow a virtual DTD that apps can handle.

Ooops, sorry for the stupid mistake above. Here's a better version:

Bill said: "Really, are we just trying to argue over a few bytes here? If so, using XML ain't a good idea at all but let's not open that can of worms (as in N3)."

No, the number of bytes is of no concern. It's the *contents* of the bytes that makes the difference. My (and I think Joe's) problem is not with RDF-the-concept at all. It is with the RDF-to-XML serialization format. Why is it that I can use an RDF Schema to say "[my:Time] is the same as [your:Time]", but I cannot say "when [my:Time] is a child of [my:Item], that [my:Item] is a resource"?

As I said in my response (linked by the first post above), I have no quarrel with RDF, and if RDF parsers and tools were better available (and more widely deployed), I wouldn't have a problem with its serialization format. But *currently* we deploy applications that work at the XML level, and at that level we simply cannot handle a general-purpose RDF document -- it must follow a virtual DTD that apps can handle.

(offtopic)

Also wondering where the 'Bird has gone, me....

(/offtopic)

here birdie birdie.......

Yeah, I'm starting to wonder about her too...
She did say she was headed out on a road trip,
but that was six days ago.

I've been wondering as well.