(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:
(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)
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.
(continued from Part I)
One of the questions you might rightfully ask, is how much impact the semantic network information within the topic map has on producing visualisations like those below:
Or how much they should have, as this is a parameter which I must control.
This is my first stab at a realistic data set (see the attachments for the original resolution):
It shows the landscape around the theme MapReduce, a cloud computing technology about which semantic web people may or may not have heard.
Hi! CatBert here.
Gosh. Robert is soooo easy to play: I only had to show him how a web application can be expressed with my TM based language TempleScript. As expected, he first appeared to be all negative about it, but I just know him too well. Now he is hooked and off doing the conceptual footwork for me.
Which allows me to sleep more and dream up more ambitious things:
A Topic Maps based mashup infrastructure.
Obviously I managed to send CatBert back into deep depression (he saw that coming, trust me).
While he sleeps in his favourite armchair, I can steal back my ideas and tuck them safely away into an academic paper. So maybe another RDFascist can entertain me with a negative review. As if a man with a vision would care.
Among the things I want to add to TempleScript are subject locator patterns. Here is the use case:
Life is full of coincidences: First I followed with interest the Ontopia web dev tutorial, then I had my more-or-less regular "TM brain storming pizza lunch appointment" with Robert (Cerny), keeping my head spinning with ideas for days. And just earlier I was passing by CatBert's office.
He was lazily typing on his CatBook:
Look what I have done with my language TempleScript!
Actually TempleScript was our idea, but CatBert had started to take ownership.
Eating Your Own CatFood
His screen showed:
This is a complete web application written in TempleScript!
[Beware: Topic Maps ahead.]
Once you reach a certain age, you seriously ask yourself whether this has been be all: wealth, fame and many beautiful women.
It is the time when you look for a more integrated meaning in the universe. A meaning which transcends all levels of abstraction. And a processing model which gets rid of the silly separation between programming language and semantic data store with its static knowledge.
(continued from Part II)
One thing Formula 3 (F3) was designed to help with is the quantitative transformation of time series. If you had to compute the mean values over an 1-hour interval of, say, the ticket sales then the following TSP operator takes care of it:
every 10 minutes
(continued from Part I)
Last time I implicitly proposed to think some parts of a (geosemantic) application in terms of time series. This is not so farfetched, consider for instance a semantically enabled tourism application for, say, Vienna.
Sure, there are a number of very static things you would store into the semantic network:
- the sites, churches, cathedral, churches, and even more churches,
- the museums, galleries, museums and even more museums,
- the tourism ontology, containing buildings, museums, and yes, the churches.
But even if this is Vienna, not everything is static: There are (insane) traffic conditions, (predominantly italian and spanish) tourists roaming through the city, concert tickets sold at the weirdest places. All these are perfect candidates to be packed into time series.
When people design semantic systems, then a typical architecture looks something like this:
- An RDF tuple (or Topic Maps) store for the odd and irregular data, and
- some relational DB, either imported into the semantic store, or wrapped, or linked via a message bus (MQ, events, ...).
- Some more or less sophisticated integration, and
- the user interface on top of it.
Now this is all well and good for your middle-of-the-road semantic portal, but the class of applications I have in mind have one thing in common:
Data dynamics, with temporal and geospatial aspects. And that with physical units.