LM in elevator, Lübeck

I'm working on a site that lists the various Topic Maps-related software that's out there, in an effort to make all the tools that have been released more visible. The site in question is, of course, Topic Maps-driven, and so it has, of course, topic pages for the people who created the tools. Those pages inevitably become pretty boring, because the tools site isn't the place to collect lots and lots of information about people.

But then it struck me: I have photos of nearly all of these people in tmphoto. Why not use those photos? And Ontopedia has PSIs for most of the people, so why not do this properly and use the PSIs to integrate the two? In fact, since there are going to be other portals with Topic Maps-related content out there, why not offer this as a generalized web service?

So that's what I did. The Topic Maps Tools topic map contains Ontopedia PSIs for people, as does the photo topic map. The person page in the Topic Maps Tools site does a request to the get-illustration service, which picks a photo of the person, and returns that. Or kind of. In practice it's a little more involved, because I wanted to be able to offer images in different sizes, to allow linking to the person's page in tmphoto, and also to allow linking to the portrait's page in tmphoto.

How it works

Technically, I've used the TMRAP get-topic-page request, and expanded it a little, by returning four types of topic pages. So what happens is that a TMRAP request goes off to the get-illustration service, and gets a TM/XML topic map containing four URIs back. Let's use me as the example. In that case, the four URIs are:

The endpoint for the service is http://www.garshol.priv.no/tmphoto/get-illustration . We follow the TMRAP get-topic-page design, so the parameter to send the PSI of the topic you are looking for is identifier . To see the example, click here. The page that sends this request is here.

I already had a nice client component for TMRAP get-topic-page requests, so that meant it was easy for me to add this to the person page in the tools application. It probably won't be as easy for others who don't use the OKS, and so don't have that component, and don't have support for TM/XML. I could add XTM 1.0/2.0 support for these people. A custom XML format there probably is no point in, because TM/XML pretty much is that already.

I had an idea for a simpler version, however, which would allow clients to get integration by rendering their HTML as follows:

<a href="http://.../tmphoto/go-to-portrait?identifier=psi" ><img src="http://.../tmphoto/get-portrait?identifier=psi">

The first URL would redirect to the portrait page, whereas the second would either redirect to the portrait itself, or perhaps even return it directly. This is not as good, however, since it would not work as well in cases where I don't have a portrait to offer. I could always return a placeholder image, of course.

Anyway, the service is there, and is free to be used by anyone for anything. If anyone wants to discuss alternative interfaces, please contact me. PSIs for people can be found either via my person page or Ontopedia's search.

Benefits of this approach

Autumn mood, Sognsvann, Oslo

Of course, it's possible to do this simply by hard-wiring the links to the photos you want in the old-fashioned way. However, this approach has more to it than being cool by simultaneously using PSIs and web services. If you already have topics for these people, and you've added the Ontopedia PSIs for them (as you should!), then suddenly you can get the photos for free. You don't need to do go through all the people, picking the photos you want, and wiring things up. Instead, doing the TMRAP call gets you the best photos automatically.

Further, as more people and photos are added on both sides, everything will just automatically update itself. If photos exist for people in the client application they will just appear. If better photos become available for existing people, those photos will automatically replace the old ones. And so on.

And nothing prevents me from becoming a photo aggregator and collecting photos from third parties and offering those to you as well. This requires the third parties to use the same PSIs and to offer a similar service (or for me to have some sort of converter), but once that happens I can seamlessly extend the reach of my service, and benefit everyone who uses it with no extra effort.

Finally, by using the PSIs you'll be able to connect to other sources of information about these people. For one thing, the tools topic map will be able to tell you if they wrote any Topic Maps tools. Other sources might get you presentations by them, their home pages and affiliations, blog postings by/about them, etc etc. So once you add the PSIs you connect to the network of (admittedly not yet existing) data sources.

Extensions

There is, of course, no inherent limitation here requiring the web service to return only photos of people. I could equally well start returning illustration photos for places (say, Leipzig), events (say, TMRA 2008), concepts (say, beer), or other things, once those things have PSIs. I will probably do that at some point, but for now I figured people was a good place to start. If anyone is interested in the extensions, let me know.