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.
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 pyramid.
- The other provides you with a more convenient and shorter way where things are supposed to be stored.
The amazing Image::Magick package can cope with images which are linked together:
my $image = Image::Magick->new;
If you resiz
(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.
But if you break it, you buy it.
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.
Yes, I am cynical. But I am not cynical enough. Despair:
(continued from Part I)
The Conventional Use Case
Objects of this class expect foremost the image to be tiled:
my $dzi = new Graphics::DZI::Files (image => $image);
As detailed in the manual page, you can add more parameters, such as tile size or the format.