Actually, regarding this very point...

One of the outcomes of Jangle is that I'd like to create a registry
(like, say, a SKOS vocabulary) that defines an identifier for an
agreed upon record format.  You point out that conneg doesn't work for
Atom or RSS payloads, but it wouldn't work, anyway.  What accept
header would you use for marcxml, mods or dc?

SRU has baked this in as part of the spec, but there's no reason we
can't adopt a convention for OpenSearch using the atom:link tag and
URIs that correspond to the above in the rel attribute.

The example I used in Jangle looked like:

<link rel="http://jangle.org/rel/alternate#http://purl.org/dc/elements/1.1/"
href="http://uri.to/your/alterate/representation" />

The jangle.org part is just a placeholder, of course, I don't care
what the URIs really look like.

What you have, though, is a URI for the kind of relationship between
the thing you have and another representation (in this case,
conforming to Atom semantics, but it could be something more
sophisticated, if there was a need) followed by the expected file
format identifier (in this case, in the straw man, I'm using the
dublin core namespace as the identifier).

This way there doesn't have to be any agreement as to how an
implementation needs to accept an argument to a particular metadata
format, just a convention on how to advertise it.

-Ross.

On Tue, Jun 24, 2008 at 3:04 PM, Godmar Back <[log in to unmask]> wrote:
> 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
>>
>