Foo/*/Edit -> Foo/Edit.aspx?f={0}

I’ve been thinking for a while about packaging it all up (for example, I also have code that lets you use UserControls from separate assemblies in ASP.NET, something that isn’t supported ‘out of the box’), so if anyone fancies testing it in return for essentially a free licence, drop me an email (stu ‘at’ feedghost ‘dot’ com).

Wow. :-)

“Skip the generic.”

Hmm. Today’s entry suggests one way that can work.

http://blog.jonudell.net/2008/01/22/bloggers-talk-to-bloggers-scientists-talk-to-scientists/

Whether or not bloggers cite generic DOIs or PubMed URLs, those forms could be discovered by the citation engines and used to thread conversation together much better than happens now.

I can see the elegance of URLs like http://example.com/item but the disadvantage to my mind is that it doesn’t pass the Steve Krug “Don’t make me think” test. In other words if I am typing in a URL like that it is probably 50/50 that I might assume that item is the name of a folder and thus type http://example.com/item/

Preference also requires a context. We may “almost always prefer HTML”, but I’d rather http://example.com/styx/come-sail-away come back as MP3 or OGG than as HTML or PDF. And heaven help us if it came back as XLS…

You yourself wrote about contextual problems:
http://jonudell.net/bytecols/2001-05-30.html
only at the time, you were addressing file-systems, not the web. But in a way the web is just a glorified file-system, so I’d say it still holds, and you can claim prognostication bragging rights. :)

[quote]
“The question then becomes ‘How does one standardize the representation of a 300 response so that it can be processed using a known vocabulary?’”

That’s a really good question!
[/quote]

My answer: Skip the generic. It becomes a mostly useless (read “underdefined) way of redirecting to alternate formats. Instead, just reference a particular (such as http://jonudell.net/phd-thesis.html ) and then within that (a known ontology), link to other formats. This is done all the time with HTML links. The MP3 version of your thesis may have you speaking the reference “This presentation of my thesis is available online at http://jonudell.net/phd-thesis.pdf and the slides are available at http://jonudell.net/phd-thesis.ppt“. The PDF version may have a link to http://jonudell.net/phd-thesis.avi for the video of your presentation.

-Tim

That’s a really good question!

“There is no web browser designed to let us choose which representation we want”

Right. We send Accept as you say, but we don’t send Prefer, even though I almost always prefer, say, HTML (if available) to PDF.

So yes, DOI’s are helpful for referencing something in the generic, but to obtain a usable representation, you have to request it in the specific. For your example, that means http://example.com/judell/phd-thesis may be what I cite, but when I fetch it, do I want the PDF version? the HTML version? the plain-text version? or perhaps an XML version? Maybe I want your spoken variant, in which case do I want it in MP3, OGG, Flac, Speex, WAV, WMA, or any of a bajillion other formats. Perhaps I want a video of you reading your thesis and defending it so I can see your slides in the background, so I request the .MOV or .AVI version.

The question then becomes “How does one standardize the representation of a 300 response so that it can be processed using a known vocabulary?”. There are an arbitrary number of facets to explore with a variety of metadata to attach, making XML (or YAML) a good candidate for representation of a 300’s content.

Using the example of a PhD thesis, you may want to convey in your 300 response an arbitrary number of facets: Rendering integrity, data/meta-data integrity, quality, size, copyright licensing, etc. The possibilities are fairly limitless:

====================
Rendering integrity: PDF or PS may be photo-exact and resolution independent; GIF/JPG/PNG may be photo-exact, but resolution dependent; HTML may be close in presentation and resolution independent; TXT may be a mere skeleton of the printed version.

Data/meta-data integrity: rendering your thesis as GIF/JPG/PNG loses a lot of information; rendering as PDF/PS/TXT loses some information but the content may still be searchable; rendering as HTML keeps some of the structural information in addition to the content; and XML may offer the strongest structuring for representation of internal structure and meta-data.

Quality (related to rendering integrity) and Size: rendering your thesis as MP3/OGG vs. FLAC vs. Speex, there’s a matter of audio quality vs. size. Speex works great for the spoken word, but if your thesis is about (and includes) music or performance

Copyright licensing: you may license the textual variants under a liberal CC license, while licensing the audio or video variants under a stricter license.

====================

Yet you can still put a default format in your Location header to transparently redirect a browser to, say, the preferred PDF or HTML version.

Just a few more thoughts on generic vs. specific content, and ill-defined 300 response content… :)

-Tim Chase

So the only way for people with browsers to request files of a certain type is to specify the file extension in the URI.

Really interesting point. Clearly I hadn’t thought this through :-)

From this point of view there’s just no point in try to make URLs more DOI-like. With a DOI, you wind up in the same place as you propose: You’re always going to get redirected.

“reflect the *content* type, not the *production method*.”
Of course there are other ways to do that, e.g.:

http://del.icio.us/rss/judell/servicemanagement
[/quote]

I just re-read through your three articles linked from there, and (assuming you gave the right link) I’m not sure I follow how the articles apply to the matter of file extensions being used to convey the file-type.

[quote src="Tim BL essay]
Consider a scientific paper that published, as many are, in .HTML and .PDF. If names were generic and content negotiation worked like it could, you get a canonical URL that would consolidate references to any of the types. Bookmarks, blog items, and other references would cluster together much better than they can when they have to hardcode differing type extensions. Connectivity and coherence would improve.
[/quote]

By offering extensions, you avail the option to refer to an object both in the generic and in the specific. If I provide a link to http://example.com/item you (or your programatic proxy) need to negociate on the terms. My GET request comes in, how does your server return a representation of that object? Either your server needs to make an assumption about my desires, or it needs to indicate that there are multiple possibilities for representing this object. HTTP does provide the “300 Multiple Choices” response code (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 for the gritty details). My end then needs to decide which representation it wants and then round-trip a second request to a distinguished entity…say one with an extension. So for a particular representation of an object, you need to convey that, and extensions make an ideal and well recognized way of doing that. It logically follows that something without an extension (a representation of an entity) is a generic. I would proffer that any URL without an extension should *always* return a 300 response code because
1) it’s the right thing to do and
2) since the user hasn’t specified the format, you shouldn’t guess. The 300 code allows for a “Location:” header to offer a suggested location.

Unfortunately, the W3 specification doesn’t define the format for offering multiple file-types in a 300 response, but only specifies that the Content-Type header should be used to encode the format the list of representations are shown in. This vacuum leaves us back where we started…plain-text? XML (and with what schema)? JSON? HTML? XHTML?

Anyways, Django (and likely other high-quality frameworks) makes this very easy to do as I can just sniff the extension and then send the resulting view’s context through a corresponding template if it exists. Or, if no extension exists, I can return a 300 with a Location: and Content-Type header to provide my suggested format (usually HTML) and a list of alternate formats (also usually in HTML, via a UL of links).