Just for the record, as a blogger I would like to say: I am not a journalist!
Ok, this writing may appear in a (reverse-chrono) journal style, but the medium, content and purpose of this, and a very large proportion of other blogs, generally bears little relation to mainstream print/TV journalism. I haven't the time, energy or motivation to explain what should be obvious.
Ok, here's an analogy. This computer contains state-of-the-art digital technology (circa 2000), a lot of the time it's hooked up to the Internet. It has a keyboard and I use it to write things - mail, stuff like this, plans, code, notes, books, even shopping lists. But...that does not mean it's a typewriter.
What's more, one or two of the louder voices amongst this Kredibility Krusade Klan are the least trustworthy people I've ever had the misfortune to encounter. Laughing all the way to their bank.
Semantic Web Outliner : blog, sourceforge (can't see a release yet). Not exactly an outliner, that's only one of the views, there's a node & arc graph there too. From Martin Dvorak in Prague (I think).
This is very very similar to what I originally had in mind for IdeaGraph, i.e. mindmaps done SemWebbically. That was before I got carried away... (I do intend to return to IdeaGraph in the next two or three months, but simplify and make it more project/goal-oriented).
Martin Schwimmer has asked Bloglines to remove his feed from their service, as he believes their use of it one their site is commercial, and goes beyond what his CC license allows. His reasoning all seems reasonable in itself, but why bother having a feed in the first place?
Ok, if I were in his position and felt strongly about it I'd have been tempted to do one of two things, depending on my mood. In a good mood then I'd insert additional references back to my blog, gain a bit of commercial flow. In a bad mood I'd put something in my robots.txt along these lines:
I got a dump of my Bloglines kiloFeed subscriptions list a couple of days ago - here's the raw opml (zip) version, here it is as RDF/XML (zip). The count has dropped quite a bit from 2500, I guess they were 404ing.
A lesson from Seven Habits Of Highly Effective People is Sharpen The Saw. Good practice for software developers. More significant in woodcarving is "sharpen the gouge". I've got a selection of oilstones, but it's important to get gouges razor sharp - literally. Doing this manually means a lot of time on a strop (I've got a block of wood with a piece of leather glued to it). Tedious. Good gouge steel is on the soft side of tool steel, so you have to strop every few minutes of carving. Tedious enough to be quite off-putting. But I found the solution a few years ago: a felt wheel on a bench grinder, but I got rid of the one I had in the uk before we moved. Caro just got me one for my birthday, this got me back in the basement again.
You can't really see in this picture, but cuts from a properly-sharpened gouge are so clean they look polished shiny (many woodcarvers consider sandpaper evil). They're also a lot more controllable, and much less effort (nice when software's like that too).
For anyone interested (this isn't Java is it...) I found it best to mod the grinder a little so the wheels turn the opposite way (up at the front, rather than down). I did this with the last one by opening it up and turning the motor around in the case. I don't have the kind of socket wrench need to get inside the new grinder so I've just swapped the guards from end to end. It does mean the power switch is on the back, but I'm using an extension lead with a switch so I don't have to reach around. I dress the felt wheel with a little "crocus powder", a very fine abrasive which comes in a solid wax-bound block. This gets the edges as required and also buffs flat areas to a mirror shine, which is rather nice.
Some more photos (for tool fetishists) over at Flickr.
What's a SWD, you may well ask...a Semantic Web Document. Tim Finin describes the Google workarounds Swoogle uses to get at RDF files (in response to the Norvig piece). The figure he quotes (2 million SWDs) still seems on the low side, I gues this doesn't include all the RSS 1.0 feeds and FOAF from places like LiveJournal. I suppose it wouldn't be unreasonable to suggest that the RSS material isn't really on the Semantic Web yet, there isn't all that much cross-linking and it's only the most recent 15 posts rather than full-site (grr, must get back to that once I get the new host sorted). On finding semantic web documents.
Ok, here's my €0.02 on the one-click feed subscription issue.
The first €0.01 is that it shouldn't be necessary for people to put other people's icons on their page. None. Imagine the Beatle's White Album with an orange [XML] in the corner... Clients only need to be a tiny bit smarter, use autodiscovery to pick up the <link> elements and make an appropriate offer to the end user. FireFox is well on the way with this.
For the other €0.01, where links are provided, the server can help by pumping out the feed with the appropriate mime type. From what I've heard this is likely to happen out of the box in many cases with Atom. Given an appropriate mime type, there's no need to use pseudo-URI schemes like feed://. Almost. There is another small piece of the puzzle that's missing, at least for RSS 2.0.
Providing a link to the feed itself within the feed, for the client handler app to pick up. RSS 1.0 should provide this already, as the channel resource. (I just noticed that TypePad at least gives the URI of the (HTML) blog instead, oops. Atom does in... does it..? Time for a post to list...)
For RSS 2.0 this problem can be solved by adding a namespaced element which points to the source feed. Ok, so you still have the problem of not being able to use the mime type in most cases. But I have a cunning plan. What if people are encouraged to add a stylesheet reference to there feeds? i.e. <?xml-stylesheet type="text/xsl" href="rss2html.xsl"?>
The stylesheet itself could be on the local server or on some friendly person's. The XSLT would render the feed in a human readable fashion, with a note saying "this is a feed" and then a set of links for either subscribing to a client- or server- side tool. Those links would be derived from the extra element pointing to the feed. This solves the problem of not being able to serve with a registered mime type, as well as presenting the end user something useful rather than a page of code.