Semergence

Querying the web might get a bit easier, with the union of SPARQL directly with HTTP. TripleSoup, a promising proposal at Apache, aims to expose Triple Stores (RDF databases) directly via HTTP.

This reminds me of URIQA, which is an effort to provide native HTTP methods for accessing metadata about a certain resource. URIQA was interesting because it allows you to say

MGET /foo HTTP/1.1

which means “Retrieve the metadata for resource `/foo`”

It looks like TripleSoup is a bit different, in that the URI in the request methods is some type of application. TripleSoup seems to be a gateway directly into the triple store, whereas URIQA masks the concept of talking to the triple store. In URIQA, it looks like the triple store *is* the server you are connecting to. With TripleSoup, the triple store is located at the URI you are sending requests to.

URIQA’s advantage is that you don’t need to know the URI to the application or triple store, you can just send an MGET to the resource. Of course, URIQA doesn’t handle queries with SPARQL.

My first question with TripleSoup is, how would I discover the URI that I can use for querying? It’s the same problem that URIQA tries to solve, “I know the URI for the resource, but I want to get its metadata.” I can ask that question in SPARQL, but who do I ask?

Best of luck to the TripleSoup team, really looking forward to the code.

Resources on Rails highlights some of the new exciting changes to appear in Rails 1.2. The most exciting is ActiveResource, which CRUDifies models as HTTP resources. Go REST!

Don’t say CRUD say FUC’D.

On how Rails is seeing the true light with CRUD, REST, and HTTP.

I have been studying Bill de Hora’s HTTPLR Specification for Reliable Messaging using HTTP. All in all I think it’s a great start to a somewhat complicated situation. It doesn’t address issues like Once-and-only-Once delivery (as multiple clients could download the same message) or ordering of the messages. It does talk about reconciling the message deliveries between client and server, in both directions.

The specification makes good use of the HTTP verbs and HTTP status codes, which I love. If they’re there, and they apply, use ‘em!

I’m going to jump into my questions about the specification, so please bear with me. If you have the time, go ahead and read the specification.

I’m a little concerned about the use of DELETE when reconciling message upload (as specified in section 8.3).

The HTTP spec reads “The DELETE method requests that the origin server delete the resource identified by the Request-URI.” To me, that says we’re deleting the /resource/ and not the /uri/.

In section 8.3 of the HTTPLR spec, we are deleting the /resource/ of the /upload exchange/. OK, that makes sense because it signals that message upload is complete.

I have trouble here: We’ve PUT our message to the /upload exchange uri/. And the HTTP spec reads for PUT: ” The PUT method requests that the enclosed entity be stored under the supplied Request-URI.”
I read this as we’ve just asked for our message to be stored by the upload exchange uri. BUT… We then delete that upload exchange resource as the signal for message completion.

I have trouble with this because, semantically, I think we just deleted our message. I know we’ve deleted the upload exchange resource, but since we PUT our message to the upload exchange uri, our message gets deleted, too.

Am I missing some piece of HTTP semantics here?

I’ve attached a picture of a possible scenario below. Basically, the Upload Exchange URI does not receive the PUT of the message contents. The message contents are uploaded in the POST, where POST has the semantics of “append this message to your collection”. The Location: header is used to return the Upload Exchange URI, which can be deleted later by the client to signify completion.

Common HTTP Implementation Problems

This document is a set of good practices to improve implementations of HTTP and related standards as well as their use. It explains a few basic concepts, points out common mistakes and misbehaviors, and suggests “best practices”.