Danny

The other day I suggested Lucky SPARQL (now SPLUCKY, thanks Kingsley), a little convention in which a SPARQL query with an additional parameter, if it's results were a single URI, would redirect to that URI. One detail I'd overlooked is that it would also be desirable to specify the Accept: type passed to the ultimate URI, but that could be given easily enough in the query parameters.

Anyhow, insomnia just brought this thing back to mind, and it occured to me that this form of queries -

http://example.org/sparql?query=SELECT+DISTINCT+... &action=redirect

- could also appear as resources in the dataset being queried and hence appear as the result of a SPLUCKY query. So one SPLUCKY query could pull out another, which would do the auto-GET thing for another and so on, hopping from URI to URI. Rather like a finite state machine.

Ok, observant readers may have noticed that this is just a glorified redirect chain/loop, not quite an FSM. But it's not far off! [said with the enthusiasm of someone who's successfully built a nearly perpetual motion machine]. In fact the shape of it (combined with insomnia) brought to mind the Turing Machine. But as you need to write to the tape, and idempotent GETs won't allow that, implementing that with SPLUCKY seems a non-starter. Although it did occur to me that if you flip it over, the URI itself could correspond to the tape, that can be modified. Whatever, these kind of machines are very similar to the way R/W Web activity happens, the similarity being more evident when shuffling resources/statements as with SPARQL 1.1. (A nice insomniscient thought is that the Web is just a fancy Turing Machine tape, and humans are the rules tables...).

Incidentally, although SPARQL has a media type "application/sparql", I couldn't see any ref in the specs to using the URI of a query in place of the query itself in the query parameters (!), i.e. something like:

endpoint/query?queryURI=http://example.org/abc.rq

Thought I'd seen that set up on an endpoint somewhere, is it specified anywhere?

Comments to G+ please

I went to bed a couple of hours ago but every time I started to drift off a mosquito buzzed by. Led to this train of thought - how would you build a Universal Turing Machine with hypertext as the engine of state?

Seemed natural to use the Web in the role of the tape in Turing's setup with URLs corresponding to the position on the tape. The path part can be tape-like. Imagine an infinite path: http://example.org/location/location/location ... To move left it's href="../location", to the right href="location/location" (I think...bit tired here :). Whatever, problem is the train crashes to the left. I'm pretty sure a single-ended tape would still be universal because it'd be like folding the normal tape and interleaving the cells. But I reckon it'd be better to stick with the standard tape config but with little sub-rules for the mapping, something like:

start at http://example.org/H

to move right:

if the final char of the URL is a L, remove it

else append a "R"

- and vice versa.

The content of the page http://example.org/HLL might then look like:

<html>

...

Symbol = 0

<a href="http://example.org/HLLL">Left</a>, <a href="http://example.org/HL">Right</a>

...

</html>

or it might 404, corresponding to Turing's blank symbol.

Reading from tape is a GET, writing is a PUT.

I think this is in keeping with the spirit of REST, there is no context kept on the server, the messages are self-contained. The client would have to know the rules for generating the new URLs, plus the instructions. Maybe a neat way of doing the instructions might be to have a series of linked scripts each corresponding to an instruction, effectively a second agent stepping through them.

Now I've had a glass of milk and a chunk of chocolate I'm off back to bed, hope that mosquito's gone. I'll leave criticism, improvement and implementation to other insomniacs.

Comments to G+

Raw

SPLUCKY FSMs

RESTful Turing Machines

Contact

Nearby

Archives

Elsewhere