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!

Advertisement