See Also: A Simple Link Server Protocol

Jakob Voß (aka Voss) has an article in the most recent Ariadne on “See Also: A Simple Link Server Protocol

His SeeAlso software is intended to fill almost much the same function as Umlaut — or at least one of Umlaut’s functions, which I describe as being a central service for known item services, which also makes it easy to embed these services in third party applications.  (See my “Rethinking the role of a link resolver“). It’s interesting to compare and contrast SeeAlso and Umlaut.

The initial technical difference I see is that Umlaut is based on OpenURL for requests, while “See Also” has a request format based on OpenSearch and unAPI put together in a certain custom way.  Among other things, this makes the See Also request a bit easier to formulate to do exactly what you want.

SeeAlso provides JSON/XML api like Umlaut, and interestingly provides some javascript helpers similar in effect (although different in execution) to what Umlaut tries to provide to make ajax inclusion in a foreign page as easy as possible. See Also actually provides a bit more flexible and simpler framework, and SeeAlso’s machine response format is a bit more well-defined than Umlaut’s “it just grew there” API response.

However, Umlaut provides more detailed information in some cases, not just a link, but what is essentially metadata about the link too.  Also, Umlaut is also capable of providing not just links, but (slightly) interactive forms for ‘search inside’ of a cited resource against third party services (live production examples in opac and link resolver)

Since Umlaut started as a link resolver, it responds to OpenURLs and provides it’s own HTML interface too, making it suitable as a drop-in replacement link resolver interface, as well as a centralized machine-to-machine generator of related links, like SeeAlso.  SeeAlso provides no user interface of it’s own, just a machine interface. Also, because of Umlaut’s origin as a link resolver, it does useful things with article-level metadata, not just book and journal-title level metadata, but I’m sure SeeAlso could be easily extended in that direction.

I’m not sure if SeeAlso is pre-checking any of the links it provides. One of Umlaut’s principles is not providing links to, say, Amazon, unless it’s verified that the given ISBN can indeed be found in Amazon. This makes Umlaut a bit slow. Umlaut’s plug-in architecture would certainly support generation of non-pre-checked links though, if this was desired. That would eliminate it’s slowness.  But since Umlaut had to deal with this slowness, it’s API provides ways for clients to check in on progress and get more results, and it’s javascript helpers also support incremental updates, instead of all at once.

I’m not sure if SeeAlso has it’s own internal database of links, rather than just generating them from a template?  Umlaut does not have any internal databases of it’s own like this, it either generates from a template and then pre-checks on the fly, or it consults external software with a database of items/links (such as SFX).

In general. my impression is that Umlaut is actually a much heavier application than SeeAlso, it does a lot more, it’s more powerful. That’s not necessarily a good thing, do one thing, do it well, keep it simple, is a good goal. On the other hand “don’t duplicate functionality” is also a good architectural principle. All of Umlaut’s expanded features came out of specific needs in my environment, and seemed at the time to logically flow from Umlaut’s central functionality.

I am intrigued by the idea of enhancing Umlaut so it can conform exactly the request/response API that SeeAlso has, it could theoretically be API compatible. I probably wouldn’t spend time on that unless I had a compelling need or use case though.

All in all, it’s interesting and exciting to see that Jakob is approaching the same sorts of problems I am, sometimes I feel like I’m the only one working in this direction!


4 thoughts on “See Also: A Simple Link Server Protocol

  1. Hi Jonathan, thanks for the detailed comparision! Sorry that I did not mention Umlaut in my article.

    Let me clarify some issues: You wrote that SeeAlso provides no user interface of it’s own, just a machine interface – that is not true, there is a HTML interface generated by XSLT from the OpenSearch description document of a SeeAlso service, see for instance

    Like Umlaut SeeAlso does not have it’s own internal database of links but you can use an internal database as source of links. The idea to pre-check links before providing them was also a major motivation behind SeeAlso. In fact SeeAlso is much simpler and thus more limited than Umlaut. One good feature of Umlauit that SeeAlso may miss is incremental updates. As far as I understand the equivalent of Umlaut’s “ServiceResponse” can only be a list of strings and links in SeeAlso. I have no intention to extend SeeAlso to provide much more (only RDF-triples and hierarchical data would be nice) because it is meant to keep simple.

    Thinking about more complex content that could be provided by a Link Resolver like Umlaut or SeeAlso I am not sure whether proprietary APIs are the right way. Maybe you can better create small services (like “search in this book”) as widgets with the Universal Widget API (UWA) – the only difference to a normal widget is that you fix some parameter with the OpenURL call and you only provide the widget under some conditions. I am not familiar enough with widgets to say whether such optional widgets that are generated on the fly would be complicated.

  2. Thanks Jakob. I definitely agree that Umlaut could benefit from using some standards-based api response, instead of it’s own. (I wouldn’t call it ‘proprietary’, because it’s all open source, but, yeah, it is custom). I just didn’t have (or didn’t spend) the time to figure out what was available and how to do this in Umlaut. Or haven’t yet. It takes more work to do this, especially when you have a fairly powerful/flexible system, but it does have benefits. But I like the idea of using the work you’ve already done in figuring out machine interfaces for SeeAlso as a model for Umlaut.

    I do think I made the right decision with the power/flexibility of Umlaut though, at least in my situation. There’s so much we can do with this kind of ‘link server’ software, if we allow it to be powerful and flexible.

    I’m curious if you guys use a commerical ‘link resolver’ product like SFX at your institution/consortium?

  3. More info on Umlaut API responses:

    There are two different response formats, one of which is complete xml (or json) data, and the other of which gives individual pieces of rendered HTML. Getting chunks of already rendered HTML is sometimes convenient when the client doesn’t _want_ to render it’s own HTML, it just wants to use already rendered HTML that Umlaut gives it and insert it into a div. But if a client wants it, the full data is available in structured XML/json too. Here are some examples:

    Complete response in XML:

    Complete response in json:

    Rendered HTML sections in XML:

    Already rendered HTML sections in JSON:

    The response formats is definitely one I just invented, it’s not based on an existing standard or anything.

    Documentation of each of the Umlaut APIs can be found on the umlaut wiki, under “APIs”:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s