It is difficult to know what is the underlying cause of all this angst. The principal suspect is surely RDF which is perceived to be somehow "difficult". Although built on a simple triples data model there is no fixed XML serialization since abbreviate XML syntaxes are supported, and it is thus not easy to capture this neatly in an XML schema language.

6:51:27 PM      comment []   trackback []  

6:21:39 PM      comment []   trackback []  

1:58:12 PM      comment []   trackback []  

1:51:46 PM      comment []   trackback []  

1:41:53 PM      comment []   trackback []  

2:35:59 AM      comment []   trackback []  

3:37:53 PM      comment []   trackback []  

Excellent indeed! The first two pages give clueful background information on metadata and why it has trouble picking up steam. The rest of the article focuses on specific metadata standards, and the author had the good sense to choose to talk about simple - but relevant and/or promising - standards first.

Page 3 covers GeoURL, and gave me the nudge I needed to get my very own  button just below my  (RSS) buttons.

Page 4 introduces Dan Bricklin's SMBeta business metadata initiative and links to the related Overall.com metadatabase. If you're curious to see what SMBeta looks like, here are small businesses with a zip code that starts with 9.

Page 5 gives a bird's eye view of the Dublin Core metadata initiative, which over the years has metastasized its way into many different other specifications.

Page 6 painlessly introduces the infamous Resource Description Framework (RDF) by way of a meaningful example (a description of the article itself).

Finally, page 7 describes the Friend of a Friend (FOAF) vocabulary and concludes by wishing good luck to all of these standards in gaining widespread adoption.

3:34:20 PM      comment []   trackback []  

3:20:22 PM      comment []   trackback []  

2:12:55 AM      comment []   trackback []  

Amazon.com Syndicated Content is delivered in RSS format. RSS is a standard format (in XML) for delivering content that changes on a regular basis. Content is delivered in small chunks, generally a synopsis, preview, or headline. Selected categories, subcategories and search results in Amazon.com stores now have RSS feeds associated with them, delivering a headline-view of the top 10 bestsellers in that category or set of search results.

This is very cool, though the feeds a little hard to find at first. Don’t look for the orange XML or RSS buttons – use RSS autodiscovery to find the feed associated with a search. (In other words, the URL will be in a link tag in the header of a search results page.)

And though I don’t really want to stir up trouble, I find it strange that Amazon uses RSS v0.91, and that they link to Netscape (an all but defunct entity) and not a spec hosted by UserLand or Harvard.

11:47:41 PM      comment []   trackback []  

6:45:12 PM      comment []   trackback []  

Link, Discuss (Thanks, mark!)
[Boing Boing Blog] 
11:42:29 PM      comment []   trackback []  



Radio Trackback Beta2 Test Whoa! Here we go ... this time with trackbackForRadio04.fttb

Nope that wiped my blog out...

[Macro error: Can't evaluate the expression because the name "adrdata" > hasn't been defined.]

Eject! Eject!

The problem seems to be connected with posts that do not have titles. I've switched back and forth between having titles and comments a few times, so many posts don't have titles - In retrospect, not a good idea

2:43:15 PM      comment []   trackback []  

5:39:15 AM      comment []   trackback []  

5:33:30 AM      comment []   trackback []  

5:00:12 AM      comment []   trackback []  

3:08:23 AM      comment []   trackback []  

2:23:25 AM      comment []   trackback []  

1:14:04 AM      comment []   trackback []  

12:02:45 AM      comment []   trackback []  

1:22:49 PM      comment []   trackback []  

• TikiWiki is **outstanding**.  There are wiki tools in virtually every language but this one is in PHP, my preference.
• A wiki once you get into it feels like bloody magic.  What's that you say?  Its fully multi-user?  It has a highly granular security model that actually works?  Oh and it can version every single page and go back in time?  Good heavens!  And its easy too...?  Damn!  Where do I sign up?
• The team members (at least Marc Laporte the one I really know) are helpful, friendly and nice.
• I'd strongly recommend a Wiki as a collaborative documentation tool for technical / engineering organizations.  This is how we're using it for Feedster -- we added our business plan to it, our engineering specs*, systems administration notes and more.

***Strongly Recommended***

1:21:56 PM      comment []   trackback []  

1:09:18 PM      comment []   trackback []  

"A Survey of APIs and Techniques for Processing XML." By Dare Obasanjo. From XML.com (July 09, 2003). In recent times the landscape of APIs and techniques for processing XML has been reinvented as developers and designers learn from their experiences and some past mistakes. This article provides an overview of the current landscape of techniques for processing XML and runs the gamut from discussing old mainstays, such as push model APIs and tree model APIs as exemplified by SAX and DOM, to newer participants in the XML world such as cursor APIs and pull model parsers. http://www.xml.com/pub/a/2003/07/09/xmlapis.html

http://xml.coverpages.org/xmlPapers200307.html#ObasanjoAPI

[Cover Pages Newsletter]

12:48:37 PM      comment []   trackback []  

3:03:23 AM      comment []   trackback []  

2:46:08 AM      comment []   trackback []  

2:38:25 AM      comment []   trackback []  

11:31:18 PM      comment []   trackback []  

10:55:04 PM      comment []   trackback []  

10:12:15 PM      comment []   trackback []  

If anyone else is running the beta, send me netomat mail so that we can mess around. I am jito on netomat. My first netomat page is here. [Joi Ito's Web Lite] 
9:52:55 PM      comment []   trackback []  



New wiki for RSS 2.0 tinkering. Thanks to Sam Ruby, the SSF-DEV mailing list now has a wiki where a draft RSS 2.0 specification can be created.

This work is unofficial -- the new RSS 2.0 advisory board is actively working on the format -- but I am hoping that it will lead to improvements that can be adopted by the board into its specification and a more solid foundation for RSS 2.0 support in the Feed Validator.

The goal of the project is incremental improvement of the format as presently specified, not dramatic changes that might break existing RSS 2.0 implementations. At this point, the main thing being worked are the item-level link and guid elements. [Workbench] 
8:12:48 PM      comment []   trackback []  



Forms that make sense. Kalsey has started a new feature on his wonderful blog. The new featured section is titled, Simplified. The first article shows how to incorporate more user-friendly form validation into your sites. It's a great article so I suggest you go... [Artima Web Buzz] 
7:57:24 PM      comment []   trackback []  



International logo contest - Wikipedia. International logo contest - Wikipedia - spreading the word. Via Wikipedia:Announcements. [Puzzlepieces] 
6:39:51 PM      comment []   trackback []  



RSS Feed Icon.

I replaced the  icon used for RSS feed with  from Bryan Bell.  Thanks to Brian for creating this wonderful icon!  I did shrink the image down a bit so it can line up with the coffee mug icon.  I hope you like it.  Now only if there was a bigger icon for Mail.  I want a red tomato with a mail stuck in it.  BTW, you are welcome to my shrunk version of the icon.

5:24:53 PM      comment []   trackback []  

"notiz" Notiz an mich: Testen! [Der Schockwellenreiter] 
5:08:34 PM      comment []   trackback []  



Bildchen für's Web. Wikipedia: Public Domain Bilderquellen. [Der Schockwellenreiter] 
5:04:30 PM      comment []   trackback []  

Has anyone yet attempted to create "RSS email", where the "feeds" served to a feedreader might be automatically synthesized from the emails themselves as things such as Person (from or to), Thread, Folder, etc?  (One could probably easily implement this as a straight layer on top of IMAP.)  Rather than just inserting RSS into an email client paradigm as in Newsgator, it might be amusing to invert the solution and explore the usability issues of rethinking email as being just another form of feed served up to a reader, with plug-ins for creating & replying, etc.  Hmm.

Has anyone yet attempted to create what I guess I'd refer to as a "Hyki" - that is, a character-by-character real-time collaborative (Hydra-like, Groove Text Tool-like) editor with automatic creation of real-time linked sub-documents when CamelCase words are typed, etc.  ??

1:21:35 AM      comment []   trackback []  

1:09:16 AM      comment []   trackback []  

1:04:47 AM      comment []   trackback []  

Maciej Wisniewski, creator of the original netomat art piece has now launched netomat.net, which gives you a desktop tool for creating multi-media canvasses that can be emailed to other users or posted to a web page, and the recipients continue to edit them. Part tool, part platform, it defies easy description -- the Writeable Drawable Voice-Annotatable Web, Hydra re-invented as a collage tool, what wikis would be like if they'd been designed by Alan Kay. As usual with odd new tools, their own home page sucks for communicating the possible uses -- netomat only starts to make sense when you make something and give it to someone else to change.

2:10:35 AM      comment []   trackback []  

12:16:57 AM      comment []   trackback []  

SVG has been dead in the water for some time, but now there are signs of some movement.  Most importantly, Adobe has released a pre-release version of SVG Viewer 6.0.  FYI, SVG Viewer is an IE plug-in for displaying SVG graphics within web pages.  I hope they keep their asses moving so that all the SVG fanatics don't end up looking like fools.  Apache's Batik team has also released the final version of Batik 1.5, a Java implementation of SVG renderer.  You can find source, binaries, and list of changes here.  Yes, it is slow so get a fast machine if you want to sell it upstairs.

If the nonsense above made you wonder what SVG might be, it is an XML-based vector graphics format whose capabilities overlap Flash and Postscript to varying degrees but has a lot more.  As you know, a lot more can be a blessing as well as a curse.  We'll see how the future turns out.  Frankly, I like SVG in the same way as a fireman might smile while watching surfers frolic on the beach as the firetruck rushes by them.

Someday.  Someday.  Hopefully on a Sunday.

2:25:24 AM      comment []   trackback []  

1:53:51 AM      comment []   trackback []  

When you need to store and display a modest amount of structured or semistructured data, it's tempting to store it directly in an HTML file. I've used this strategy many times; undoubtedly you have too. The advantages and disadvantages of working directly with a presentation format are pretty clear. It's handy that the "database" is a self-contained package that can be updated using any text editor, emailed, read directly from a file system, or served by any web server. But it's awkward to share the work of updating with other people or to isolate and edit parts of the file as it grows. When we convert to a database-backed web application in order to solve these problems, we trade away the convenience of the file-oriented approach. Can we have our cake and eat it too? This month's column explores the idea that a complete web application can be wrapped around an XHTML document, using XSLT for search, insert, and update functions. [Full story at O'Reilly Network]

12:43:51 AM      comment []   trackback []  

• djbdns: Domain Name System tools
• Taking a Stand on (n)Echo - The .NET Guy
• howto: code Archives

4:43:39 AM      comment []   trackback []  

This is an ultra-liberal feed parser, suitable for reading RSS and Pie feeds as produced by weblogs, news sites, wikis, and many other types of sites.

As I guessed and as Mark replied, his ultra-liberal feed parser now supports initial Pie (nee nEcho (nee Echo (nee Pie))) feeds.

But you know what else? He left in support for RSS. My news aggregator remains fully able to read all my feeds even after dropping in his new code. No breakage here. [0xDECAFBAD] 
4:34:06 AM      comment []   trackback []  



Target Post.

This is a dummy post that will act as a target for trackback pings.

I'm now testing the trackback send-ping functionality from the Radio client.

4:11:44 AM      comment []   trackback []  

2:13:51 PM      comment []   trackback []  

Oxen bloxsom purple communities. EE Kim speaks!.

Eugene Kim has started blogging: EEK Speaks.

Eugene and his partner, Chris Dent (who blogs at Glacial Erratics), of Blue Oxen Associates, both have PurpleNumbers on their blogs, where each paragraph has its own fragment permalink.

Eugene wrote a plugin for his bloxsom blog, and Chris is generating his in Moveable Type. Chis also sends these paragraph level links out in one of his RSS 2.0 feeds.

PurpleNumbers are something totally good for the iCite net, which likes links to content at as fine a granularity as interesting, like a paragraph.

[the iCite net development blog]

I had the pleasure to meet Gene during Planetwork conference.  Somehow they convinced Pierre Omidyar to fund them! 

[Marc's Voice]

I have a question about PurpleNumbers which is:

• What happens when the paragraph gets edited?

Does it get a new purple number?  If so, where does the old purple number go?  If not, how do you find out that the paragraph you are linking to is no longer the paragraph you thought you were linking to?

12:50:08 AM      comment []   trackback []  

We've not made much noise about it but something that Paolo and I have been doing is working within the framework of RSS2.0 to deliver what we see as useful functionality.  ENT 1.0 is one of those things, another is SGUID.

SGUID allows an aggregator to unambiguously identify the post that an aggregated post is referring to.  By default RSS2.0 only allows you to identify the feed.  The upshot of SGUID is that aggregators could implement simple threading and allow readers to browse back through a series of postings with ease. Whenever I repost an item from my aggregator now, my post get's the appropriate SGUID.

SGUID is simple.  We're hoping it is useful as well.

12:47:30 AM      comment []   trackback []  

12:30:07 AM      comment []   trackback []  

12:19:26 AM      comment []   trackback []  

Want an idea of what your RSS feed would look like as Echo? Tristan Louis has a converter to do just that. Here is BitWorkings feed as (not)-Echo, which by the way, validates using the recently updated Feed validator.

12:15:54 AM      comment []   trackback []  

12:11:02 AM      comment []   trackback []  

12:10:35 AM      comment []   trackback []  

The idea here is that I don't want to search everything in Feedster but just the blogs I read i.e. the ones I search. This relies on you having an OPML file of the blogs that you read. This is produced by some but not all news aggregators. For example Radio produces one that is always stored in the location /blog/gems/mySubscriptions.opml. Feedster has the ability to read your opml file from any URL and then use to restrict your search.

Here's how to do this:

1. Go to Feedster's Advanced Search page
2. In the OPML field add the url to your OPML. Here's the url to Ross' OPML: http://radio.weblogs.com/0114726/gems/mySubscriptions.opml
3. In the Search field add what you want to find (use wiki for example).
4. Here's the result (305 results).
5. If you didn't use the OPML then here's the result (5,000+ hits)

4:15:25 AM      comment []   trackback []  

10:19:50 PM      comment []   trackback []  

6:00:41 PM      comment []   trackback []  

5:29:49 PM      comment []   trackback []  

5:04:34 PM      comment []   trackback []  

2:14:31 PM      comment []   trackback []  

2:12:58 PM      comment []   trackback []  

1:54:00 PM      comment []   trackback []  

Jeremy Helms converted his logo to ASCII. Cool!

1:43:52 PM      comment []   trackback []  

It no longer suggests an element to remove in response to invalid RSS 2.0 (and perhaps other versions).

He also says this about the validator, which is an open-source project:

The RSS validator has always been neutral in the RSS wars. In particular, it provides valuable feedback on the quality of RSS 1.0 feeds as well as RSS 2.0. In fact, most of the code is common between the two.

If somebody were to wish to constructively contribute to this effort, particularly one with strong Python skills, he or she would be eagerly welcomed by me.

1:22:06 PM      comment []   trackback []  

Almost nothing of what [Ted] Nelson imagined has come to pass. He was wrong about transclusion, wrong about stateful conversations, wrong about how to handle unique IDs, and almost everything that [Tim] Berners-Lee did right -- limited semantics in the application protocol; made it stateless; and created the 404 error, living embodiment of worse is better and savior of scale -- violated Nelson's bankrupt vision. Xanadu was the wrong answer, REST (Representational State Transfer) is the right one. If you thought that all that was wrong with RSS 1.0 is that RDF didn't make it confusing enough, attach the twin boat-anchors of OWL and the Semantic Web to Echo and see what happens.

1:19:22 PM      comment []   trackback []  

6:23:51 AM      comment []   trackback []  

• Teal Sunglasses: Dear Dave...
• XPath

5:41:16 AM      comment []   trackback []  

Gary Lawrence Murphy reached a similar conclusion as I have: emergence of value-added RSS feeds.  Checkout the second half of his "Echos of RSS" post.

4:09:04 AM      comment []   trackback []  

If you don't have the time to keep up with the Echo Wiki stop by Aaron Swartz' Echo Project News for all the latest developments.

4:02:06 AM      comment []   trackback []  

The next revision of the draft EchoAPI RFC is now available:

http://bitworking.org/rfc/draft-gregorio-02.html

and if your are curious, the original XML is also available:

http://bitworking.org/rfc/draft-gregorio-02.xml

Changes from the last version:

1. Entries are no longer returned from POSTs, instead they are retrieved via GET.
2. Cleaned up figure titles, as they are rendered poorly in HTML.
3. All content-types have been changed to application/not-echo+xml.

3:41:02 AM      comment []   trackback []  

7:42:57 PM      comment []   trackback []  

6:56:09 PM      comment []   trackback []  

6:49:19 PM      comment []   trackback []  

Joi cooks up a little Moblogging magic with Sony...

Sony Image Station with MetaWeblog API.  It's a moblog gateway. It receives email from a cell phone with a photo attached. The Sony team made an XML RPC metaWeblog API interface to Sony Image Station. We take the picture, talk to Sony Image Station using metaWeblog API and post the picture in a photo album. Then the gateway talks to Movable Type using the metaWeblog API to create an entry with the thumbnail from Image Station that clicks thru to the full picture on the Image Station site. The text and the title get entered into Movable Type and the category is pre-set. We are using the metaWeblog.newMediaObject (which Movable Type current supports) to send the images. Please support this standard so photo sites can use the API.

3:27:50 PM      comment []   trackback []  

In a single HTTP Request/Response transaction there are a total of six places that information can be stored. If you are designing a web service, which of the six you choose depends on the context, i.e. where and how your service is going to be used.

For an illustrative example, consider this elided request/response from the draft EchoAPI RFC. Here is the request:

POST /reilly HTTP/1.1
Content-Type: application/not-echo+xml


<?xml version="1.0" encoding='iso-8859-1'?>
<entry> 
    <title>My First Entry</title> 
    <subtitle>In which a newbie learns to blog...</subtitle> 
    <summary>A very boring entry...</summary> 
    ...
</entry>

And the response is:

HTTP/1.1 201 Created
Content-Type: application/not-echo+xml


<?xml version="1.0" encoding='iso-8859-1'?>
<entry> 
    <title>My First Entry</title> 
    <subtitle>In which a newbie learns to blog...</subtitle> 
    <summary>A very boring entry...</summary> 
 
    <link>http://example.org/reilly/2003/02/05#My_First_Entry<;/link>
    <id>urn:example.org:reilly:1</id>
    ...
</entry>

The six different locations to store information are:

1. The request URI. Okay, this is the first line of the request and also contains the method, like GET or PUT, I'm lumping them together to simplify things.
2. The request headers, in RFC 822 format, you might remember that I've talked about RFC 822 Headers before.
3. The request message body.
4. The response status code. This is the first line of the
5. The response headers, again in RFC 822 format.
6. The response message body.

That's a lot of choices. When designing a service it's not always clear where some components of a message should be placed. For example, if you are attaching to a service that requires authentication, do you encode the authentication information into the requesting URI, do you use one of the HTTP authentication mechanisms which puts the authentication in the request headers, or do you put a name and password into the message body being sent? You could also send custom HTTP headers with authentication information. None of the choices are inherently better than another. All of the choices have their pros and cons, and each are appropriate depending on the context.

For example, Bulu, the code that runs this site, encodes the authentication information in the URI when doing Editable Comments. It's the least secure method, but the given the context, editing comments on a weblog, it's adequate. On the other hand, Bulu uses one of the HTTP Authentication mechanisms when creating or editing entries. That action requires more security than editing comments.

So where should you store your information? Beats me, but just keep in mind that as you design your service that you have six places to choose from.

3:17:23 PM      comment []   trackback []  

3:12:24 PM      comment []   trackback []  

3:42:14 AM      comment []   trackback []  

3:24:36 AM      comment []   trackback []  

3:20:36 AM      comment []   trackback []  

I have posted an updated version of the EchoAPI Draft RFC, which includes the following updates:

1. Renamed from EchoAPI.html to follow the more commonly used format: draft-gregorio-NN.html.
2. Renamed all references of URL to URI.
3. Broke out introspection into it's own section.
4. Added the Revision History section.
5. Added more to the warning that the example URIs are not normative.

As always, drop by the wiki to to provide your feedback.

3:14:05 AM      comment []   trackback []  

3:12:25 AM      comment []   trackback []  

3:11:00 AM      comment []   trackback []  

3:10:28 AM      comment []   trackback []  

First de facto standard Blog API was Blogger API by Evan Williams.  It was naive in design and had some design peculiarities like appkey puzzled others, but it worked.  Evan's "experimental" disclaimer lost its merit when his API was taken up by others without him complaining loudly about it.

Dave Winer then designed MetaWeblog API to supplement Blogger API with some notable overlaps in features.  MetaWeblog API is a classic example of 'embrace and extend' strategy which has many benefits as well as many problems.  One such benefit is taking of initiative which is the opening note of many war songs.

Both Evan and Dave had the opportunity to remove the danger of confrontation when MetaWeblog API was being designed.  Unfortunately, neither did so.  In fact, both aggrevated the situation by Dave not supporting appkey parameter from MetaWeblog API and Evan starting work on Blogger API 2.0.

I think both Dave and Evan are responsible for the mess we have today and I see little chance of a universal Blog API emerging for a while.  If I had the power to dictate things, I would have the Echo project adopt the union of Blogger API 1.0 and MetaWeblog API as Echo API 0.0 and extend it as needed without breaking backward compatibility.

Will everyone involved sacrifice their prides, ideals, and needs for the good of all?  Maybe, just itty bitty miraculous maybe.

Update #1: I thought I should make some of the implications of my proposal clear:

• Echo API 0.0 will be just as pretty as it is now.  Will you choose beauty and elegance over universal Blog API and continuity?
• Members of Echo project will control the future of the universal Blog API.  If you want some control, join the project.
• All the blogging tools will continue to work.
• XML-RPC binding must be supported.  SOAP and REST binding are up to the Echo project.

Lastly, I don't want people to send me their opinions, questions, nor criticisms.  Time for discussion is over.  If you want it to happen, just do your part without worrying about others doing their part.  Trust me, you have everything to lose by doing it, so mine as well do it without thinking about it.

4:07:41 AM      comment []   trackback []