Categories
Web

The turbulent waters of RSS

Recovered from the Wayback Machine.

I was pleased and rather surprised to see so many comments attached to my posting on RDF. As to be expected with recent discussions, the thread soon turned to issues of RDF/RSS. That’s cool.

What isn’t cool is something such as this by Morbus Iff and Dave Winer’s absolutely atrocious response. Saying something such as:

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. Their perversion may even be the reason they’re involved.

Over the line. What I especially can’t understand with the essay is why Dave brought Ben Hammersley into this particular discussion. The reason looks to be because Ben didn’t include Radio in the RSS aggregators discussed in an article he wrote for The Guardian. Dave called Ben’s article tainted just because Radio — which is a weblogging tool, not a pure news aggregator — wasn’t mentioned.

Calling Morbus on inappropriate joking is one thing. Publishing Morbus’ name, attacking Ben, and calling Bill and Morbus ‘monsters’, is another.

The RSS discussion continues I gather over at Blogroots as well as RSS-Dev.

Time to move on. Let Userland have RSS if they wish. The folks involved with RDF/RSS should come up with a different name, as simplified a syntax as possible that is still valid RDF, and let folks use what they want. If some folks want to use XSLT to transform RDF/RSS to Userland RSS, or the reverse, fine. But this is a technical trick and kludge and shouldn’t even be considered as part of a specification.

I would also strongly recommend that the newly renamed and reformed RDF/RSS working group define the intent and focus of RDF/RSS so that it doesn’t become “one XML to rule them all”, in their interest of creating the perfect syndication format. And since the group would be in the process of many changes, I would also suggest that the RDF/RSS working group move their discussions to another venue other than Yahoo groups, with all its many annoying ads. It’s becoming increasingly difficult to follow the threads: the quotes from previous messages overwhelm the new content, the mix of discussions about spec minutia and group working matters with grand overall schema changes is perplexing and off putting to new people getting involved, and on and on.

It’s also past time for the RDF folks, other than just Dan Brickley, to start getting involved. In particular, I wouldn’t mind seeing the RDF working group folks with weblogs. I have found this to be an excellent format for opening conversations with one’s target audience.

As for myself, I’ll only support an RDF-based aggregation newsfeed at my web sites because I believe this is the better approach. If this means my feeds aren’t readable by some aggregators, okay, I can live with this. This will be an unfortunate side effect on not being able to pull reasonable people together to come up with a combined specification (and note that I don’t consider that a lot of the players in this little farce to be ‘reasonable’, a statement thereby pissing off all participants equally).

Personally, I think a widening of this particular rift is a positive rather than a negative event.

Postscript: You know, there are no women involved in the RDF/RSS working group or the RDF working group. I think this should change. Perhaps I should lurk less and talk more. Any other lady techs in the audience wish to join me?

Categories
Semantics Technology

RDF: As simple as A, B, C

When I demonstrated a very simplified RDF/RSS model last week, in the comments attached to the post, Ziv asked the following question:

One question of an RDF newbie: Why do we need that (rdf:Description) element? Why can’t we simply put the @rdf:about attribute on the (item)?

As I started to answer the question in the comments, I kept finding myself taking the question deeper and deeper into the meanings of RDF:

-The rdf:about attribute can’t be used directly on a property led to

-The RDF/XML follows a striped XML syntax of class/property/class/property, regardless of shortcuts led to

-The striped XML syntax is based on the pattern of node-edge-node in RDF led to

-The node-edge-node of RDF is based on a model

All of which led me to a truly definitive question about RDF — why? Why the use of rdf:about here rather than there. Why the syntax? Why the model? After all, XML is a piece of cake — an element here, an attribute there, slam dunk in some text and hey now, we got data. Why make things more complex than they need to be?

Why? Because XML is great about collecting data but is lousy about recording knowledge. There is no facility inherent within the plain vanilla flavor of XML that allows one to write or read assertions in such a way that these assertions (read this as ‘statements’) can be machine produced and machine-readable. And the machines need all the help they can get.

We humans don’t need a rigorous model to communicate. We have phonemes that form words that make up a vocabulary, members of which are then used to form sentences through the use of this really irritating set of rules called “grammar”. We’re programmed to apply these rules through years of instruction, using a neural networking technique called ‘education’. When programming is finished, and after passing certain quality assurance tests, we’re set upon the world. Once loosed from the constraints of the lab, we promptly and as quickly as possible throw out much of what we’ve learned in favor of imagination, creativity, and a dangerous little nugget called innovation.

I love it.

Dorothea wants to discuss her specific mindset related to ‘sexism’ and the concept of sexiness and uses a new word: grunch. This word doesn’t exist, but we as humans adapt to it, add it to our vocabulary (phonemes: grrr + unch). In future writings based on Dorothea’s original discussion, we know what grunch is. Humans adapt.

In 1986, Hans Gabler made 2000 ‘corrections’ to James Joyce’s Ulysses. Well, thank goodness he did because nobody read it the way it was, all those grammatical errors and typos kept getting in the way. Most likely no one even heard of this book until Mr. Gabler took it in hand. As grateful as I am, though, I have recently discovered an even better re-write of this classic: Ulysses for Dummies.

I digress. XML and RDF.

With XML I can record pieces of data such as date, an excerpt, a title, author, category and so on. The structure of the markup allows machines to read these individual facts, to verify that the recording meets certain simple rules. But what if I want a little more than just plain facts. What if I want to be able to take these facts out for a spin, kick the tires, check under the hood?

I have a web page. Facts about this page are: title, URL, date edited, category, and author.

Page has title. Page has URL. Page has edit date. Page has author.

Tarzan has Jane. Jane has Cheeta. Cheeta has banana. A pattern is beginning to emerge.

Every sentence has a subject and a predicate. The subject is the focus of the sentence, and the predicate says something about the subject. These two basic components work remarkably well in allowing us to communicate, to share amazingly complex knowledge.

Returning to RDF and XML, using straight XML is equivalent to only allowing communication with one verb — To Have. Following this, an XML translation of the previous paragraph would be:

Sentence has subject. Sentence has predicate. Sentence has focus. Subject has focus. Predicate has information. Subject has information. Predicate has subject. Components have power. Communication has components. We have each other.

As you can see, after a time, the simplicity breaks down — we need to increase our capabilities, even though doing so adds complexity.

Enter RDF, providing a structure and a meta-language to XML, a grammar if you will.

RDF has one pattern: (subject)(predicate)(object). However, this pattern gives us the tools to record data in such a way that knowledge can be inferred mechanically, merged via a well understood and defined logic with other knowledge, and so on. The subject is the noun, the focus of the statement; the predicate says something about the subject; the object is what is said.

Taking the test paragraph, it can be re-written into the following RDF-like statements:

(Sentence) (has a component)(which is a subject)
(Sentence) (has a component)(which is a predicate)

— no, no, don’t worry — it does get better

(The subject)(is the focus of)(the sentence)
(The subject)(is described by)(the predicate)
(Sentence Components)(enable)(communication)
(Sentence Components)(enable sharing)(of knowledge)

By providing the ability to record this subject-predicate-object pattern, RDF allows us to expand on the depth of information we gather. The more complex the information, the deeper the pattern is applied, but it is still this triple. In a graphical context, the subject-predicate-object form into a node-edge-node that allows us to build new statements on previously occurring ones.

The focus OF the sentence IS the subject DESCRIBED BY the predicate WHICH IS a component OF a sentence. Consider in this sentence that the predicates are the capitalized value, the graphical notation of this could be: node-predicate-node-predicate-node-predicate-node-predicate-node-predicate. Nothing more than a repetition of our friend the triple, connected end to end.

Representing this within XML requires a set of syntactic rules that ensure we don’t accidentally shove a predicate next to a predicate and so on. There are rules for how to identify a subject, and how to add a predicate. There are rules for how to repeat properties (predicate-object pairs), and how to group properties. There are even rules for how to create a statement about a statement (known in RDF as ‘reification’, though I prefer ‘RDF’s Big Ugly’, myself). But fundamentally the rules break down into nothing more than node-edge-node-edge-node, forming a particularly interesting XML pattern called The Striped RDF/XML syntax.

Rule’s that basically say that predicates can’t be nested directly beneath predicates (edges next to edges) or that whole node-edge-node thing gets blown out of the water. And rules that state when an rdf:about attribute can be applied. In my simplified RDF/RSS, the rdf:about attribute can’t be applied directly to the ITEM element because ITEM in this instance is acting as a predicate, with an implied URI of “item” — it can’t act as a new subject, too. Edge-edge.

So, with a little tweaking (adding the subject within a generic RDF resource statement, as in example 1, or using a shortcut as in example 2), the rules are met and the knowledge can be processed.

(Check out the example RDF files with the RDF Validator to see a graphical demonstration of node-edge-node.)

Once you’ve described one data set with these rules, interferences can be made to other data sets made with the same rules.

As an example, RSS is nothing more than a quick news blurb that gets consumed in less than 24 hours and doesn’t persist. The power of RDF isn’t necessary for RSS used by aggregators, primarily because the data doesn’t persist and one thing about the search for knowledge: it does require that the bits of the knowledge stick around long enough to be discovered.

However, RSS captures a rich set of information about a specific web page or weblog posting: the author and creation date, as well as category, and possibly even links to other resources. What a pity to put this into a form that will only be thrown away.

Well, who says it has to be thrown away? We’s all bosses here, we is. If I says to keep it, I’s boss, and you listen up or Bird be real angry, she will. Real angry. Hissy fit angry.

I modified my individual weblog posting archives to include a bit of RDF in the header that contains the same information used to produce the RSS files that aggregators so callously consume and toss aside. Since this modification was in the template, this RDF is generated for each page automatically. And once persisted in the archive page, it’s there for anyone to discover, providing a richer set of data than just that assumed with keywords pulled from the text.

In this RDF is an identification of the author, an entity which is rounded out by a FOAF (Friend-of-a-Friend) RDF file; knowledge of me, who I am, adds depth and categorization to my Book Recommendation list RDF, and so on and on — a vicious cycle of knowledge acquisition.

(Archived page and comments at Wayback Machine)

Categories
Semantics Technology

RSS: Proof is in the implementation

Sam Ruby had taken a first shot at RSS 2.0 with an RSS document demonstrating the new, simplified RSS syntax. No evidence of RDF, RSS version, no RDF Seq.

Mark expanded on this with what looks to be the same specification, different examples and the use of included HTML (parseLiteral in RDF terms). (Correct me if I misread this Mark).

Since Sam has published an example of his version, allow me to work with the assumption that whatever works with his proposed RSS 2.0 should work with Mark’s, with the addition of HTML literals.

In this weblog page, I have PHP processing for the Book recommendation list. I copied the page and modified it to process Sam’s new proposed RSS file. You can see it in action here. The process took me about 10 minutes because the SHIFT key on my laptop doesn’t work well, and I am using vi to make the edits.

Now, I want to show you something. Here is my MT generated RDF/RSS file. Taking this and Sam’s and Mark’s proposed RSS 2.0, I came up with a simplified RDF/RSS syntax, seen in this file and also duplicated here:

<?xml version=”1.0″?>

<rdf:RDF xmlns:rdf=”http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:dc=”http://purl.org/dc/elements/1.1/” xmlns=”http://purl.org/rss/1.0/”>

<channel rdf:about=”http://weblog.burningbird.net/”>
<title>Burningbird</title>
<link>http://weblog.burningbird.net/</link>
<description></description>

<item>
<rdf:Description rdf:about=”http://weblog.burningbird.net/archives/000514.php”>
<link>http://weblog.burningbird.net/archives/000514.php</link>
<title>Myths about RDF/RSS</title>
<description>Lots of discussion about the direction that RSS is going to take, which I think is good. However, the first thing that
happens any time a conversation about RSS occurs is people start questioning the use of RDF within the…</description>
<dc:subject>Technology</dc:subject>
<dc:creator>shelley</dc:creator>
<dc:date>2002-09-06T00:53:16-06:00</dc:date>
</rdf:Description>
</item>

<item>
<rdf:Description rdf:about=”http;//weblog.burningbird.net/archives/000515.php”>
<link>http://weblog.burningbird.net/archives/000515.php</link>
<title>ThreadNeedle Status</title>
<description>I provided a status on ThreadNeedle at the QuickTopic discussion group. I wish I had toys for you to play with, but no
such luck. To those who were counting on this technology, my apologies for not having it for…</description>
<dc:subject>Technology</dc:subject>
<dc:creator>shelley</dc:creator>
<dc:date>2002-09-06T00:19:28-06:00</dc:date>
</rdf:Description>
</item>

</channel>

</rdf:RDF>

Differences are:

 

  1. RDF element rather than RSS
  2. No versioning – not necessary with the concept of namespaces
  3. Use of namespaces to differentiate modules
  4. Surrounding the ITEM’s properties with a RDF:Description. The ITEM can have either literal data or XML elements that should be parsed. By using RDF:Description, I’m giving a hint to the processors that what follows is XML data to be parsed for new elements, so turn off literal text processing optimization, and use the more memory and CPU intensive XML parser, please.

Notice that there is no RDF:Seq in this RDF/RSS version. Why? You don’t have to use the Seq element for valid RDF. I believe Seq was used with RSS 1.0 because the originators of RSS 1.0 wanted to provide ordering information to the tool builders. However, this really seems to be an absolute sticking point with everyone. Fine. Dump it.

Run my new RDF/RSS through the RDF validator (here), and you’ll see it’s valid RDF.

Now, I created a third copy of my weblog page with the PHP processing and had it parse and print out this new RSS file. The changes necessary? I changed DC:DATE to DC:CREATOR — I wanted to print out the latter not the former. Here’s the new page.

Next, I copied the PHP page and had the code process my original RDF/RSS 1.0 file, the one that’s generated automatically from MovableType. Changes to the code? Nada. Not one single change other than the name of the RDF file. Time to make change? 4 seconds. See the new page here.

Now, all of these pages (including this one) use PHP-based XML processing to process the data (xml_parser). No specialized RSS or RDF APIs. Pure XML processing. And it took me about, well, honestly, probably a couple of hours to write the original code for my Books RDF/RSS application. That darn shift key you know.

I’m not trying to downplay other’s concerns or existing work or effort, and I realize that I have a better understanding of RDF than most of you (not bragging, but give me this as an accepted for discussion purposes at this moment) and that this gives me an edge when working with RDF.

What I’m trying to show is that keeping RDF in the RSS specification doesn’t nececssarily mean that simplified processing is impossible, or that we can’t use ‘regular’ XML tools, and that there will be a huge burden on tool writers.

We don’t have to keep Seq if it really bothers everyone. Let’s work this change. Let’s. Let us work this change. I like that phrase, don’t you?

By keeping RDF in RSS now — and really are those changes I made to the proposed RSS 2.0 so hard to swallow? — we keep the door open for the benefits that will be accured some day when RDF does have broader use.

I guess what I’m trying to show, demonstrate, prove is that RDF doesn’t have to make things arbitrarily complicated, or confusing. That we can write documentation that clarifies those few bits of RDF in the specification so that it isn’t complicated for folks writing or reading this stuff by hand (or processing it with various languages).

I’m hoping with this demonstration that I’ll convince a few of you that we can keep the door open on this discussion rather than arbitrarily throwing RDF out — a specification I’d like to gently remind you all that’s been in work for years by some of the best markup minds in the business. And as easy as it is to criticize the RDF working group for taking time, remember that they’re trying to create a specification that will stand the test of of time, rather than break through every version, as we had with HTML.

Mark provided a summary of the RSS issue, and I know that this discussion has been going on for years. And I know that there are a lot of people who say, let’s just fork. But folks, this didn’t work for SQL and QUEL (remember QUEL?) years ago when the decision was being made about which query format to use when accessing relational database data. I really do want to see these specs come together, with members and players from all sides.

And I’ll also be honest and say that I really don’t want to see this owned by any private company or person. Sorry, but I just can’t accept this, it goes everything I believe in. I am not belittling Dave’s and Userland’s contribution to RSS. I realize that Userland popularized RSS and a debt is owed.

What I am asking is that Dave become part of a team working on this, a team that’s open to people who literally have something to contribute on this issue, each with an equal vote. Yes, people like me, like Mark, like Sam, Jon, Joe, Bill — all the people who have something to contribute to make this specification rock. And hopefully prevent something like this from happening again in the future.

Am I too late though? Is the decision made? Can’t we talk?

Where’s the fire?

(Archived page and comments at Wayback Machine)

Categories
Technology

Threadneedle status

Recovered from the Wayback Machine.

I provided a status on ThreadNeedle at the QuickTopic discussion group. I wish I had toys for you to play with, but no such luck. To those who were counting on this technology, my apologies for not having it for you, and unless someone can point out an obvious solution to the problems I’ve recounted that I’m too dense to see (a good possibility that), chances are ThreadNeedle will remain an RDF schema without an implementation.

On a related not, I also wanted to specifically mention that Ben & Mena’s (of MovableType) development of the standalone TrackBack server was a remarkably generous gesture, one that I hadn’t given the proper due. I believe that the Trotts have gone above and beyond in how much they’ve given the weblogging community, and deserve kudos from me, not tired, cranky grumblings.

I don’t know if you all have taken the time to read what the Trotts have said, but they’re putting this server out under Artistic license and encouraging people to use their technology, no charge. This means developers can incorporate this technology into their own applications — such as ThreadNeedle, which is one thing I am examining. Or into other webloggings tools for that matter.

Damned if I’ve seen anyone thank Ben & Mena for this. I didn’t. I’ll amend this now — thank you Ben and Mena.

 

Categories
Technology

Myths about RDF/RSS

Lots of discussion about the direction that RSS is going to take, which I think is good. However, the first thing that happens any time a conversation about RSS occurs is people start questioning the use of RDF within the RSS 1.0 specification, and the necessity of keeping RSS “simple”.

Mark Pilgrim writes:

Many people in the RSS community feel that, while the lack of extensibility in RSS 0.9x is too limiting, the full-blown RDF syntax of RSS 1.0 is overkill for the purposes of syndicating weblogs.

Jon Udell writes:

RSS is becoming too complex. It needs to remain simple, human-readable and -writable.

Well, this just plain peeves me. Not Mark or Jon’s statements, but the idea that a) RSS must be human readable and writeable and b) RDF makes RSS overly complex.

Specifically, there are three myths I want to address:

Myth 1. RDF adds complexity to RSS because the RDF Seq element is unnatural and adds an extra layer of processing.

Hanging from a tree dressed in orange, purple, and lime green while reciting the Gettysburg Address and drinking a glass of water dyed blue at the same time is unnatural. The use of RDF containers (which is what the Seq element is) in RSS is to provide some structure to the data. (See my RDF/RSS file, generated by Movable Type for examples during this dicussion.)

The RDF Seq container provides an explicit ordering — top down — to all the elements contained within the tag. Without the Seq element, there is only an implicit assumption that all items are processed in a certain order.

I’m not fond of RDF containers myself principally because there is built-in processing associated with them, though I understand their use in maintaining relationships between elements; however if I was a tool builder, I would at least understand what Seq means, and that helps eliminate confusion about the specification. If you didn’t have the RDF Seq container, there might be an assumption that the item ordering is important, but there’s nothing enforcing this assumption.

Not using the Seq container is as bad as the defining the <em> element in HTML — exactly what are we, as tool builders, supposed to provide with this element?

Joe: Well, I’m building my browser to use italic font, same weight and line height as the surrounding text. That’s emphasis.

Sara: Well, I’m building my browser to use a bolder font, and to increase the size as well. This is emphasis we’re trying to define here.

Dubya: Em? Auntie Em?

Myth 2. RSS must be human readable/writeable

Let’s get real about markup: markup is not human readable and writeable. I don’t care if you’re talking SGML, HTML, or XML, markup is not meant to be created and consumed by humans. Now, we may adapt and learn to work with markup. However, we can also adapt to spending 8 or more hours a day in a small, cramped, walled in, windowless, artificially lighted and ventilated environment, too, and that’s no more human than markup reading and writing. Markup exists to be generated by automated processes and consumed by automated processes.

All you webloggers out there that create your RSS feeds by hand, raise your hands. Now, those with their hands in the air, dump whatever tools you’re using to build your weblogs and get Moveable Type and let the machines do what we pay them to do.

Myth 3: RDF doesn’t add anything to RSS

I remember a debate several years back about how the relational data model was too complex and didn’t add any value to a company’s business.

RDF is the relational data model of XML. Now, it’s true, I’m writing a book on the subject and am biased. However, I’m writing the book because I believe in the concepts of RDF, I don’t believe in RDF because I’m writing a book on it.

RDF provides a structured meta-data language that can be used to define any XML vocabulary, providing rules to ensure that all instances of the XML that use the vocabulary are consistent with one another. In addition, with RDF you have a host of pre-built tools and APIs that allow you to access the data from many different business vocabularies with little or no change to the underlying technology. May not seem like much, but believe me, this will get you buy in on new technology at a company faster than whether there’s a version tag in the specification. After all, it worked for Oracle.

I’ll have more to say on this debate but it’s late, and I’m tired. Another day.