TM::IP RESTful documents

Last year I extended my Topic Maps implementation into several directions. One was to host also documents as part of a topic map. With such a construct you can do a number of things: Have a fulltext search over the map, have text-to-map transformations, or build graphical map representations.

Now this is all good and well when working with an API and having all local on a box. But the scenario I have in mind is that people can manage their content (topic map and documents) via the network.

Good'n'old TMIP

Now for topic map content I had already built long ago implementations for TMIP. I have never published those packages (TM::IP::Client, TM::IP::Server), mostly because the implementation used its own HTTP server and that would not cooperate nicely with an existing Apache. But I am now in the process to move all that RESTful goodness to Catalyst. And that has an impressive integration with the Perl build process and the CPAN package management system.

New'n'Shiny Document Store

What was missing, and what I did this weekend, is to implement a simple document repository controller. With it you can do so exciting things as download, upload and delete files:

GET http://server/internet/web/.docs/architecture.html

PUT http://server/internet/web/.docs/architecture.pdf

DELETE http://server/internet/web/.docs/architecture.pdf

How cool is that.

So if you had a RESTful client (Python, Ruby, Perl), you could now upload your map, upload some documents attached to the map, and then ... well what?

What Then?

The document store is just only one aspect of a stored map. Other aspects are the fulltext index over that map, feature vectors computed from the map, or a PNG representing the map content.

Also for these other aspects I will implement a REST API, so that you will be able to say at some stage:

GET http://server/internet/web/.surface/x3/20x12.png

That would find the 2D surface of the topic map, at zoom level 3, and there tile 20x12. Rendered as PNG.

So if you had a RESTful client, you could then download the map, in pieces or as a whole.

TempleScript Coordination Language

Writing clients is ok, but in my case I will have to manage content on several boxes, be that for load balancing or be that for content-political reasons (content is always political).

It would be nice to use a language for that, something on the command line.   > http://server/internet/web/.docs/web-arch.html

When run through the TempleScript interpreter (dubbed the priest), it will download (GET) the left-hand side URL and will PUT it against the URL on the right.

Maybe the language is also topic-mappish in the first place: If the document should become a dedicated topic, then

$d isa document
! Web Architecture

$d >> http://server/internet/web/

will do the trick of adding it. The >> will trigger a POST against the URL.

I need more rainy weekends.

Posted In

Yeah, baby!

Again I must chip in with "hey, that's what I'm doing, too!", before I mention that you should perhaps peek at for the mURL DSL, and then I'll just mention that my REST framework now is getting a proper TM overhaul as well. The link between PSIs and URIs in REST is staggering. :)

Alex (not verified) | Mon, 03/30/2009 - 02:05

Re: Yeah, baby!

Again I must chip in with "hey, that's what I'm doing, too!"

And Robert Cerny too! :-) And probably a RESTful, handfull of other people as well. Would be nice to see more specs.

The clause with the authentication is neat.

My priest will be purely functional, though. So there is no state, as there is in

GET ...

Instead, there are only filters and content can only be "fetched, piped, posted". Topics (in TM-speak) are constants in this language. Something like that.

rho | Mon, 03/30/2009 - 05:30