Print

Print


I too find this decision intriguing, and I'm wondering about its wider
implications on the use of RSS/Atom as a container format inside and
outside the context of OpenSearch as it relates to library systems.

I note that an OpenSearch description does not allow you to specify
type of the items contained within a RSS or Atom feed being
advertised. As such, it's impossible to advertise multiple output
formats within a single OpenSearchDescription (specifically, you can
only have 1 <Url> element with 'type="application/rss+xml"').
Therefore, clients consuming OpenSearch must be prepared to interpret
the record types correctly, but cannot learn from the server a priori
what those are.

My guess would be that OCLC is shooting for OpenSearch consumers that
expect RSS/Atom feeds and that have some generic knowledge on how to
process items that contain, for instance, HTML; but at the same time
are unprepared to handle MARCXML or other metadata formats. Examples
may include Google Reader or the A9 metasearch engine.

The alternative, SRU, contains no expectation that items by processed
by clients that are unaware of library metadata formats. In addition,
its 'explain' verb allows clients to learn which metadata formats they
can request.

This may be reviving a discussion that an Internet search shows was
very active in the community about 4 years ago, although 4 years
later, I was unable to find out the outcome of this discussion, so it
may be good to capture the current thinking.

What client applications currently consume OpenSearch results vs. what
client applications consume SRU results?

I understand that a number of ILS vendors besides OCLC have already or
are in the process of providing web services interfaces to their
catalog; do they choose OpenSearch and/or SRU, or a heterogeneous mix
in the way OCLC does. If they choose OpenSearch, do they use RSS or
ATOM feeds to carry metadata records?

 - Godmar

On Tue, Jun 24, 2008 at 1:23 PM, Jonathan Rochkind <[log in to unmask]> wrote:
> In general, is there a reason to have different metadata formats from SRU vs
> OpenSearch? Is there a way to just have the same metadata formats available
> for each? Or are the demands of each too different to just use the same
> underlying infrastructure, such that it really does take more work to
> include a metadata format as an OpenSearch option even if it's already been
> included as an SRU option?
>
> Personally, I'd like these alternate access methods to still have the same
> metadata format options, if possible. And other options. Everything should
> be as consistent as possible to avoid confusion.
>
> Jonathan
>
> Washburn,Bruce wrote:
>>
>> Godmar,
>>
>> I'm one of the developers working on the WorldCat API.  My take is that
>> the API is evolving and adapting as we learn more about how it's
>> expected to be used.  We haven't precluded the addition of more record
>> metadata to OpenSearch responses; we opted not to implement it until we
>> had more evidence of need.
>> As you've noted, WorldCat API OpenSearch responses are currently limited
>> to title and author information plus a formatted bibliographic citation,
>> while more complete record metadata is available in DC or MARC XML in
>> SRU responses. Until now we had not seen a strong push from the API
>> early implementers for more record metadata in OpenSearch responses,
>> based on direct feedback and actual use.  I can see how it could be a
>> useful addition, though, so we'll look into it.
>>
>> Bruce
>>
>>
>
> --
> Jonathan Rochkind
> Digital Services Software Engineer
> The Sheridan Libraries
> Johns Hopkins University
> 410.516.8886 rochkind (at) jhu.edu
>