Preview

Comment:

Posted by

Comment

Name: You must provide your name.
Email*: You must provide your email address.
  *Please provide your real email address; it will not be displayed as part of the comment.
Homepage:
Comment**:
  **The following markup may be used in the body of the comment: a, abbr, b, br, code, em, i, p, pre, strong, and var. You can also use character entities. Any other markup will be discarded, including all attributes (except href on a). Your tag soup will be sanitized...
What is six times three?
  In an effort to reduce the amount of comment spam submitted by bots, I'm trying out a simple CAPTCHA system. In order to submit your comment, you must answer the simple math question above. For example, if asked "What is the two plus five?", you would enter 7.
Remember me? (Want a cookie?)

 (There must be no errors before you submit.)

The body of the essay you are commenting on appears below. Certain features, such as the navigation, are not supported in this preview. I might someday fix that. Or not.

Hacking httpRange-14.

In real life, unlike in Shakespeare, the sweetness of the rose depends upon the name it bears. Things are not only what they are. They are, in very important respects, what they seem to be.

— Hubert H. Humphrey

Semantic web enthusiasts among my readers will have encountered the “hash vs. slash” debate, perhaps most famously in the TAG's attempt to resolve the range of HTTP: URIs.

When I first started this weblog, I knew it was going to be built on top of a semantic web framework, not out of any fervent belief that it's the future, but out of the conviction that I won't be able to say whether or not I think it's the future if I don't try it out.

I also knew about the hash vs. slash debate.

While I was never entirely convinced by the arguments of the “anti-slash” camp, I decided to simply avoid the issue by using a hash. There's never been any argument about hashed URIs, only slashed ones. As a result, the identifier for me, my physical person, became:

  1http://norman.walsh.name/knows/who#norman-walsh

As time passed, this had a practical consequence. If you dereferenced that URI, the server would send you the whole “who” file that contained all the metadata about everyone. That file got to be big.

I ignored this problem as long as I could, simply living with the inconvenience, but when I decided to support “link groups” I faced a real hurdle.

The obvious URI for the “link group” about me is the URI that identifies me. But linking to the hashed URI made following the link way too expensive to be of practical value. I could have cooked up an alternate URI for the link group, but that would effectively have been an alias. Aliases: bad.

Unable to come up with a workaround I liked, I decided it was time for a big bang: I decided to change a whole lot of URIs. Instead of using a hashed URI to identify me (and everyone and everything else), I'd use a slashed one:

  1http://norman.walsh.name/knows/who/norman-walsh

In order to do this, I felt I needed to implement the TAG resolution on httpRange-14. Which I've done:

  • A GET on http://norman.walsh.name/knows/who/norman-walsh returns a 303 redirect to http://norman.walsh.name/knows/who/norman-walsh.html.

  • The HTML at http://norman.walsh.name/knows/who/norman-walsh.html includes a link to the metadata:

      1<link rel="alternate" type="application/rdf+xml"
  2      title="Metadata" href="norman-walsh.rdf" />

    which I hope helps semantic web software find the underlying metadata.

  • That metadata in turn contains

      1<owl:sameAs rdf:resource="http://norman.walsh.name/knows/who#norman-walsh"/>

    which tells the semantic web agent that this URI is entirely equivalent to the former hashed URI.

Hopefully this all “just works” in every meaningful way.