Uncooked

Link Condom

This is agonizing:

Stop the spread of Viral Link Skank today.

THE SOLUTION......wait for it.....

rel="nofollow"

(spotter: Jeremy)

The gentle path to feed subscription

I hope it's been clear from what I've posted recently that I consider the icon/browser based approach no more than a fallback from autodiscovery (using the HTML <link> element - not only for RSS autodiscovery, it can also be for FOAF autodiscovery etc).

But anyhow Ken MacLeod wraps it up neatly, getting rid of the link to machine-readable data but adding:

...have Bryan Bell design a graphic that conveys, "this page can be subscribed-to". This is a visual clue to those who are familiar with aggregation but, more importantly, it's a link to page on how to become familiar with aggregation.

There is no cheap data

I really want to respond at length to Tim Bray's post What Do Tags Mean?, but I've got work to do. I'll limit myself to two points - Tim says (regularly) "There is no cheap metadata." I don't think that's true, or particularly relevant. For example, all my outgoing mail contains my name - data or metadata? What's the cost? In general this question should be balanced with: what's the benefit?
If you have high benefit/cost, is that cheap or merely good value?

The other point is regarding tags, taxonomies, namespaces, structured vocabularies and personal ontologies. Tim's right about the difference between Technorati's flat approach and Atom's potentially structured approach, but there's been a lot of work done in this area.

In a summary form, it's all there in Morten's FOAF Output Plugin.

Oh, and a different angle is Pietro's Delicious Mind Map Maker, which shows how you can elicit structure from the flat stuff.

Lame Mac audio?

I recently did a bit of Java to demo "Podcasting" in the book. It uses the (pretty mature) Tritonus plugins alongside the (pretty standard) LAME mp3 encoder. Anyhow the tech editor reasonably grumbled that it wouldn't/couldn't work on a Mac (I wrote it on Win2k). The Tritonus docs are a bit thin, so I asked on their mailing list. First response was entirely positive (and I revised the book text accordingly). But then I got the following :

Sorry to intervene on one minor detail: the lame encoder wrapper lametritonus.dll will not work on MacOS! So even that LAME works on MacOS, and so does tritonus (the java part), the link is missing. It is possible that recompiling liblametritonus.so on MacOS will work with a MacOS version of liblame.so, but I am not aware that or if someone has succeeded in doing so. In contrary, I"d expect some problems that prevent compilation "out of the box".

(full thread)

On the offchance I thought I'd mention it here, in case anyone happened to be working on podcasting/audio/Java/Mac stuff, might have a minute (!) to try compiling the missing link. Here's the code I did (zip, 320k) (needs the Tritonus plugins for mp3 encoding & decoding and their dependencies, see filelist.txt & README.txt), should be ok on Win/Linux with recent Java, should get nowhere on a Mac...

The Feed Subscription Problem

PS: (oh, doesn't work - maybe they haven't got RSS 1.0 support yet, it is new)

I just posted the following in comments over at Brent Simmons' regarding approaches to simple feed subscription, posted here so I can find it again. The issue has been characterised by Dave Winer as the "Yahoo Problem". Phil Ringnalda has given a good (if slightly paranoid) analysis of the political issue in comments at Brent's - summary: If we don't offer something that works as well for people without an aggregator as links to MyBigThree, we won't be fighting about mime-types vs. pseudo-protocols, we'll be fighting about the best way to write a bookmarklet that rewrites links to them back into links we can use to subscribe.

Somewhere between politics and practicalities, Winer's offered a vague solution that sounds centralized, and depends on aggregator developers suppporting him. More practically, there's the feed: URI scheme, and Randy Charles Morin has written up the mime-type based approach, he calls it the Universal Subscription Mechanism.

I'd assume that autodiscovery (via HTML page <link>s) was the first line of attack, the second line being a link on a persons's Web site, the second line getting all the attention at the moment. Anyhow, my $0.02:

It might be a good time to stand back and do a sanity check.

For a start, I'm not certain there's such an imminent threat to civilization as it's been portrayed, we've had these calls to "circle the wagons" many times before. So CNN include links to Yahoo's aggregator - if they also include a direct feed link, so what? If they don't include a direct feed link, then it's *their* loss, because fewer people will be subscribing. There is little doubt that there will remain a role for "third party" aggregators like NetNewsWire and FeedDemon for a long time to come, and it won't be marginal - there's a considerable proportion of feed publishers who have absolutely no intention directly leading people to Yahoo's (Microsoft's, Google's) aggregator.

I'm sure it's possible to solve the immediate issue of the "Yahoo Problem" given support of a significant proportion of aggregator developers - whether or not the solution is a good one. If everyone outside of Yahoo supports a single approach, then Yahoo will be compelled to follow that approach. But how is this different than say Microsoft, Google or Yahoo dictating a single approach? Bullying is bullying, whoever's doing it.

The Web is all about diversity, but paradoxically that diversity is enabled by standardization. Whether application-level standardization is desirable is another question. I would suggest standardization works best at the level of protocols and formats, not on user interface behaviour.

But ok, if something has to be done, and a level playing field is part of the issue, then shouldn't the approach be in the open? Shouldn't it additionally be something that conforms to good practice (as found in e.g. the webarch doc), to avoid conflict with other developments?

My own personal situation is that I've (just barely) got the opportunity to include a little about the technical side of this issue in a book. Whatever the commercial/political side of this problem, there still needs to be some code in there somewhere. Right now I can see the mime-type approach, the feed:// approach and Dave saying he has a solution - but it's secret and for it to work you must do what you're told...

Dave's unknown instructions aside, I can't actually see must conflict between these approaches, implementing one doesn't rule out implementing the other. Having a plurality of solutions at least to begin is quite in line with previous developments on the Internet. Selection in the environment may trim this down to a single approach, or different approaches may come along. That seems more Web-friendly than a single approach being decided by diktat.

So I'd conclude, for a start, that there's no need to panic. These There are strong reasons in favour of what Randy's suggesting. The feed:// approach runs contrary to good practice, though may be ok as a stopgap. If Dave can offer something more tangible than "vote for me" then perhaps it too could be considered more seriously. But I doubt whether the "Yahoo Problem" will be best solved by any single approach.

PPS. Oops, I also forgot to mention Morten's subscription service.

The Blogosphere as a Tuple Space

Les Orchard consider The Blogosphere as a Tuple Space.
Heh, this was in his comments:

Since I don’t understand either concept in detail, I’ll ignorantly ask, “Is this somehow different from the Semantic Web?” They sound the same to me.

The kF Project

David Janes picked up the kiloFeed challenge (actually 2.5kF, that's > 3 Scobles), and got 2500 blogs comfortably readable in Sparks!. I've not played with it yet (currently downloading Sparks 1.7.13-beta), but if David's previous work is anything to go on, this should be good.

He also made a project of me. Heh, thanks David, I've always wanted one, since I heard Alan Parsons had one...

QOTD

With the following illegal rdf/xml I'd like to express that the default abnormal-termination message if "Requiem in pax" which are Latin words, but the English version is a blinking "Rest in peace"...

Reto Bachmann-Gmuer on www-rdf-interest.

Universal Feed Subscription

Universal Subscription Mechanism from Randy Charles Morin. Yep, this is more like it.
Inserts an <atom:link> element into the feed pointing to the source URI. Depends on the server responding with the mime type "application/rss+xml". He suggests discouraging the use of "application/rdf+xml" - I'm not sure that is necessary (or desirable).

PS. nearly missed this - he's also done some code implementing the client side, see this blog post.

RSS 1.1

Spec. Incorporates bugfixes and changes due to 2004 RDF specs. Closely resembles the "BridgeBuilding" proposal suggested as a fork-unifying RSS 2.0.

Example:

<Channel xmlns="http://purl.org/net/rss1.1#" 

   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 

   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>

<image rdf:parseType="Resource">

   <title>XML.com</title>

   <url>http://xml.com/universal/images/xml_tiny.gif</url>

</image>

<items rdf:parseType="Collection">

   <item>

      <title>The Restful Web: Amazon's Simple Queue Service</title>

      <link>http://www.xml.com/pub/a/2005/01/05/restful.html</link>

      <description>

         In Joe Gregorio's latest Restful Web column, he explains that 

         Amazon's Simple Queue Service, a web service offering a queue 

         for reliable storage of transient messages, isn't as RESTful 

         as it claims.

      </description>

   </item>

   <item>

      <title>Transforming XML: Extending XSLT with EXSLT</title>

      <link>http://www.xml.com/pub/a/2005/01/05/tr-xml.html</link>

      <description>

         In this month's Transforming XML column, Bob DuCharme reports 

         happily that the promise of XSLT extensibility via EXSLT has 

         become a reality.

      </description>

   </item>

</items>

</Channel>