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.
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 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!