Now that my maps and all the supporting vector space data is getting larger, I noticed that HTTP::Request (as well as HTTP::Response) are not overly economic when it comes to memory usage.

The Problem Definition

Let us look at the following code

Just yesterday I attended a first working brunch related to the Austrian OGov Data Initiative. The workshop had the goal to detail the data we are interested in and also to define the overall goal and degree of formality ( detailed results).

The turnout was very good, with a good mix of individuals, university people, smart companies. Needless to say, I saw no observer from the public sectors.

And - being a methusalemic Internet person - I had some flashbacks, reaching back into the early 90'ies.

The BIBOS "Experience"

I was university assistent at that time. And while I was supposed to write my thesis, I rather preferred to experiment with this new thing called the Internet.

Advice: Do some reading before writing me. I mean it.

(continued from Part III)

Now that I know where the documents are located in the landscape, I have experimented with ways to estimate where the topic map topics are supposed to be. My hypothesis is that if I can determine the distance of each document to every topic, I can triangulate the topics.

Topic Positions

Below (larger version in the attachments) is a new rendering of the MapReduce theme:

It shows the themes derived from the semantic corpus (documents + semantic network). Compare this with the positions of topics:

There are two major additions:

• The first allows you to use a whole image stack as canvas for your image pyramide.

• The other provides you with a more convenient and shorter way where things are supposed to be stored.

Image Stacks

The amazing Image::Magick package can cope with images which are linked together:

If you resize or otherwise operate

(continued from HD Semantic Maps)

Like most of you, I collect bookmarks. But unlike most of you, I store them into a semantic network, a topic map to be precise.

One problem I certainly share with you, is that all these laboriously collected links are prone to break. To recover them sometimes needs considerable effort and - according to another Murphy Law (are there actually any other laws?) - always hits you at the most inappropriate time.

(continued from part III)

Over the last year I had hardly time to advance my Perl client to the AllegroGraph tuple server. Which is a shame, as it is fun to take the existing REST interface and to offer it in a perlish mindset.

So when the Perl hackathon (report) was in Vienna these days, and coincidentally also the RDF Perl hackathon Geilo next week, I thought I should use the opportunity to a rub shoulders with the Perl illuminaries, at least for half a day. But when I arrived, everyone was already in deep hacking mode, so I had no excuse but to do programming myself.

(continued from Part III)

Lately I invested more work in the backend server (TM::IP) to also host the document positions: Positions of those documents which - together with the underlying semantic network - form the landscape.

The theme is still MapReduce, but with considerable more content than before.

Seamless document access

On top of Seadragon I then implemented a bit of mouse hover logic to be able to preview HTML and PDF pages directly onto of the map.

**Play with it!**

But if you break it, you buy it.

Since the last release there have been a few smaller additions, such as

• a simple entropy computation in TM::Analysis, and

• an neighborhood functionality into TM::Graph.

Both I need for the map visualisation toolchain.

I also fixed some problems when using maps with the MLDBM backend.

For my latest Perl projects I have switched from ExtUtils::MakeMaker with its Makefile.PL to Module::Build.

So far I have been using it quite naively, but this time I had special requirements:

I am packaging a server (TM::IP), so there are not only Perl packages and a client-side script (ts), but also the daemon code and the configuration files:

Up to yesterday, for my Topic Maps REST server (tmipd) I have used startup and shutdown scripts to control it, quite in the Apache tradition:

On start, it would detach from the terminal and would daemonize.

When I created an experimental version of the Perl client RDF::AllegroGraph::Easy it worked against the AG server 3.1.1.

Since then some subtle changes occurred, so that I have upgraded the client to continue to work.

Franz Inc. has also provided me with a pre-release of AG 4.

Yes, I am cynical. But I am not cynical enough. Despair:

Category Economy

(continued from Part I)

When you need to integrate the generation of DZI image pyramids into your own infrastructure, you should look first at Graphics::DZI::Files and not its superclass Graphics::DZI.

The Conventional Use Case

Objects of this class expect foremost the image to be tiled:

As detailed in the manual page, you can add more parameters, such as tile size or the format.

If installed properly, the Graphics::DZI distribution should also contain a script deepzoom which can be used from the command line.

With it you can take an image (in any format ImageMagick can interpret) and generate the image pyramid as necessary for deep zooming with the Seadragon AJAX client.