Re: [CODE4LIB] use of OpenSearch response elements in libraries?
On Tue, Jun 24, 2008 at 10:48 AM, Ross Singer [EMAIL PROTECTED] wrote: Theoretically you should be able to also pass the argument record_type=dc or record_type=marc to give you dublin core or marc21, but there seems to be a bug there. I'll fix that today. Bah, this actually did work, I just had a typo in the URL I was using to make sure it worked. I need unit tests on my big, fat, dumb fingers, I think. -Ross.
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
[ this discussion may be a bit too detailed for the general readership of code4lib; readers not interested in the upcoming WC search API may wish to skip... ] Roy, Atom/RSS are simply the container formats used to return multiple items of some kind --- I'm curious about what those items contain. In the example shown in http://worldcat.org/devnet/index.php/SearchAPIDetails#Using_OpenSearch it appears that the items are only preformatted citations, rather than, for instance, MARCXML or DC representation of records. (The SRU interface, on the other hand, appears to return MARCXML/DC.) Is this impression false and does the OpenSearch API in fact return record metadata beyond preformatted citations? (I note that your search syntax for OpenURL does not allow the choice of a recordSchema.) If so, what's the rationale for not supporting the retrieval of record metadata via OpenSearch? - Godmar On Tue, Jun 24, 2008 at 10:17 AM, Roy Tennant [EMAIL PROTECTED] wrote: To be specific, currently supported record formats for an OpenSearch query of the WorldCat API are Atom and RSS as well as the preformatted citation. Roy On 6/23/08 6/23/08 • 10:18 PM, Godmar Back [EMAIL PROTECTED] wrote: Thanks --- let me do some query refinement then -- does anybody know of examples where record metadata (e.g., MARCXML or DC) is returned as an OpenSearch response? [ If I understand the proposed Worldcat API correctly, OpenSearch is used only for pre-formatted citations in HTML. ] - Godmar On Tue, Jun 24, 2008 at 12:54 AM, Roy Tennant [EMAIL PROTECTED] wrote: I believe WorldCat qualifies, although the API is not yet ready for general release (but soon): http://worldcat.org/devnet/index.php/SearchAPIDetails Roy On 6/23/08 6/23/08 € 8:55 PM, Godmar Back [EMAIL PROTECTED] wrote: Hi, are there any examples of functioning OpenSearch interfaces to library catalogs or library information systems? I'm specifically interested in those that not only advertise a text/html interface to their catalog, but who include OpenSearch response elements. One example I've found is Evergreen; though it's not clear to what extent this interface is used or implemented. For instance, their demo installation's OpenSearch description advertises an ATOM feed, but what's returned doesn't validate. (*) Are there other examples deployed (and does anybody know applications that consume OpenSearch feeds?) - Godmar (*) See, for instance: http://demo.gapines.org/opac/extras/opensearch/1.1/PINES/atom-full/keyword/?s e archTerms=musicstartPage=startIndex=count=searchLang which is not a valid ATOM feed: http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fdemo.gapines.org%2Fop a c%2Fextras%2Fopensearch%2F1.1%2FPINES%2Fatom-full%2Fkeyword%2F%3FsearchTerms% 3 Dmusic%26startPage%3D%26startIndex%3D%26count%3D%26searchLang -- --
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
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
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
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
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
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 [EMAIL PROTECTED] 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
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
Wow, I'm coming into this thread late ... To answer Godmar up-thread, Evergreen's OpenSearch service returns data in more than 15 formats, including MARCXML and MODS. It was actually the first ILS to do so (with the exception of Ross's Voyager add-on), and also the first ILS to have an unAPI service (which it embeds link elements to expose -- part of the non-validation you pointed out). Non-validation (by extension) is an acceptible trade-off in my opinion, since feed readers (the main consumers of ATOM and RSS today -- think a Saved Searches folder in Google Reader or Live Bookmarks your bookmark toolbar) have no problem with the data. Some examples: HTML, with links: http://dev.gapines.org/opac/extras/opensearch/1.1/-/html-full?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword MARCXML: http://dev.gapines.org/opac/extras/opensearch/1.1/-/marcxml?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword MARCXML with some extensions (view source): http://dev.gapines.org/opac/extras/opensearch/1.1/-/marcxml-full?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword MODS: http://dev.gapines.org/opac/extras/opensearch/1.1/-/mods3?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword OAI DC: http://dev.gapines.org/opac/extras/opensearch/1.1/-/oai_dc?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword RSS 2.0: http://dev.gapines.org/opac/extras/opensearch/1.1/-/rss2?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword and even a catalog card mock-up: http://dev.gapines.org/opac/extras/opensearch/1.1/-/htmlholdings?searchOrg=PINESsearchTerms=harry+pottersearchClass=keyword On Tue, Jun 24, 2008 at 3:36 PM, Ross Singer [EMAIL PROTECTED] wrote: [snip] What accept header would you use for marcxml, mods or dc? According to the W3C, application/marc-xml or similar (the '-' instead of '+' says it's not a registered MIME type). However, browsers don't work with that well. Put a '+' in there and they'll (generally) render the XML. -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
I believe WorldCat qualifies, although the API is not yet ready for general release (but soon): http://worldcat.org/devnet/index.php/SearchAPIDetails Roy On 6/23/08 6/23/08 8:55 PM, Godmar Back [EMAIL PROTECTED] wrote: Hi, are there any examples of functioning OpenSearch interfaces to library catalogs or library information systems? I'm specifically interested in those that not only advertise a text/html interface to their catalog, but who include OpenSearch response elements. One example I've found is Evergreen; though it's not clear to what extent this interface is used or implemented. For instance, their demo installation's OpenSearch description advertises an ATOM feed, but what's returned doesn't validate. (*) Are there other examples deployed (and does anybody know applications that consume OpenSearch feeds?) - Godmar (*) See, for instance: http://demo.gapines.org/opac/extras/opensearch/1.1/PINES/atom-full/keyword/?se archTerms=musicstartPage=startIndex=count=searchLang which is not a valid ATOM feed: http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fdemo.gapines.org%2Fopa c%2Fextras%2Fopensearch%2F1.1%2FPINES%2Fatom-full%2Fkeyword%2F%3FsearchTerms%3 Dmusic%26startPage%3D%26startIndex%3D%26count%3D%26searchLang --
Re: [CODE4LIB] use of OpenSearch response elements in libraries?
Thanks --- let me do some query refinement then -- does anybody know of examples where record metadata (e.g., MARCXML or DC) is returned as an OpenSearch response? [ If I understand the proposed Worldcat API correctly, OpenSearch is used only for pre-formatted citations in HTML. ] - Godmar On Tue, Jun 24, 2008 at 12:54 AM, Roy Tennant [EMAIL PROTECTED] wrote: I believe WorldCat qualifies, although the API is not yet ready for general release (but soon): http://worldcat.org/devnet/index.php/SearchAPIDetails Roy On 6/23/08 6/23/08 € 8:55 PM, Godmar Back [EMAIL PROTECTED] wrote: Hi, are there any examples of functioning OpenSearch interfaces to library catalogs or library information systems? I'm specifically interested in those that not only advertise a text/html interface to their catalog, but who include OpenSearch response elements. One example I've found is Evergreen; though it's not clear to what extent this interface is used or implemented. For instance, their demo installation's OpenSearch description advertises an ATOM feed, but what's returned doesn't validate. (*) Are there other examples deployed (and does anybody know applications that consume OpenSearch feeds?) - Godmar (*) See, for instance: http://demo.gapines.org/opac/extras/opensearch/1.1/PINES/atom-full/keyword/?se archTerms=musicstartPage=startIndex=count=searchLang which is not a valid ATOM feed: http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fdemo.gapines.org%2Fopa c%2Fextras%2Fopensearch%2F1.1%2FPINES%2Fatom-full%2Fkeyword%2F%3FsearchTerms%3 Dmusic%26startPage%3D%26startIndex%3D%26count%3D%26searchLang --
