Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Since we generally return results asynchronously to client systems from our MSSE (fed/meta/broadcast/aggregated/parallel/Multi-Server/Search Engine) I would just point out that we use other protocols than SRU when doing so. When we do use SRU on the client side, then we send back the results in a complete set. Otherwise we send them in tranches on a timescale controlled by the client system, usually about every 2 seconds. Obviously an SRU-async protocol is possible, but would it be used? As a MSSE we would use it to get results from Sources, so they could be processed earlier (smaller response time) and more smoothly. But that would require Source servers implemented it, and what would their incentive be to implement it? For direct use with end users it would mean a browser client capable of retrieving and managing the partial data is needed. Middleware systems (between the MSSE and the user) would need to support it, and pass the benefit to the user. Any system doing heavy analysis of the results would probably not want (and may not be able) to start than analysis until all the results are obtained, because of the added messiness of handling partial results sets, from multiple Sources (it is messy - believe me). I would be very happy to see such a protocol (and have it implemented), and if Jakub implemented browser code to handle that end, then the users could benefit. Peter Peter Noerr CTO. MuseGlobal www.museglobal.com > -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Jakub Skoczen > Sent: Tuesday, May 18, 2010 12:51 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current > drafts > > On Tue, May 18, 2010 at 9:17 PM, Ray Denenberg, Library of Congress > wrote: > > First, no. There are extensibility features in SRU but nothing that > would > > help here. > > > > Actually, Jonathan, what I though you were suggesting was the > creation of a > > (I hesitate to say it) metasearch engine. I use that term because it > is what > > NISO called it, when they started their metasearch initiative five or > so > > years ago, to create a standard for a metasearch engine, but they got > > distracted and the effort really came to nothing. > > I'm not sure if Jonathan was suggesting that but that's exactly what I > had in mind - using SRU 2.0 as a front-end protocol for a meta-search > engine. And yes while creating a third-party, SRU-inspired protocol > for that purpose could work, I see very little value in such exercise. > I suspect that, as any standard, SRU has certain limitations and, as > an implementer, you have to work around them but you do end up with an > obvious gain: standards compliance. SRU-inspired protocol is not quite > the same thing, and it's probably easier to go all the way and create > a custom, proprietary protocol. > > > The premise of the metasearch engine is that there exists a single- > thread > > protocol, for example, SRU, and the need is to manage many threads, > which is > > what the metasearch engine would have done if it had ever been > defined. This > > is probably not an area for OASIS work, but if someone wanted to > revive the > > effort in NISO (and put it on the right track) it could be useful. > > > > --Ray > > > > > > -Original Message----- > > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf > Of > > Jonathan Rochkind > > Sent: Tuesday, May 18, 2010 2:56 PM > > To: CODE4LIB@LISTSERV.ND.EDU > > Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current > drafts > > > > Jakub Skoczen wrote: > >> > >>> I wonder if someone, like Kuba, could design an 'extended async > SRU' > >>> on top of SRU, that is very SRU like, but builds on top of it to > add > >>> just enough operations for Kuba's use case area. I think that's > the > >>> right way to approach it. > >>> > >> > >> Is there a particular "extensibility" feature in the protocol that > >> allows for this? > >> > > I don't know, but that's not what I was suggesting. I was suggesting > you > > read the SRU spec, and then design your own "SRU-async" spec, which > is > > defined as "exactly like SRU 2.0, except it also has the following > > operations, and is identified in an Explain document like X." > > > > Jonathan > > > > > > -- > > Cheers, > Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
On Tue, May 18, 2010 at 9:17 PM, Ray Denenberg, Library of Congress wrote: > First, no. There are extensibility features in SRU but nothing that would > help here. > > Actually, Jonathan, what I though you were suggesting was the creation of a > (I hesitate to say it) metasearch engine. I use that term because it is what > NISO called it, when they started their metasearch initiative five or so > years ago, to create a standard for a metasearch engine, but they got > distracted and the effort really came to nothing. I'm not sure if Jonathan was suggesting that but that's exactly what I had in mind - using SRU 2.0 as a front-end protocol for a meta-search engine. And yes while creating a third-party, SRU-inspired protocol for that purpose could work, I see very little value in such exercise. I suspect that, as any standard, SRU has certain limitations and, as an implementer, you have to work around them but you do end up with an obvious gain: standards compliance. SRU-inspired protocol is not quite the same thing, and it's probably easier to go all the way and create a custom, proprietary protocol. > The premise of the metasearch engine is that there exists a single-thread > protocol, for example, SRU, and the need is to manage many threads, which is > what the metasearch engine would have done if it had ever been defined. This > is probably not an area for OASIS work, but if someone wanted to revive the > effort in NISO (and put it on the right track) it could be useful. > > --Ray > > > -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Jonathan Rochkind > Sent: Tuesday, May 18, 2010 2:56 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts > > Jakub Skoczen wrote: >> >>> I wonder if someone, like Kuba, could design an 'extended async SRU' >>> on top of SRU, that is very SRU like, but builds on top of it to add >>> just enough operations for Kuba's use case area. I think that's the >>> right way to approach it. >>> >> >> Is there a particular "extensibility" feature in the protocol that >> allows for this? >> > I don't know, but that's not what I was suggesting. I was suggesting you > read the SRU spec, and then design your own "SRU-async" spec, which is > defined as "exactly like SRU 2.0, except it also has the following > operations, and is identified in an Explain document like X." > > Jonathan > -- Cheers, Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
> in order to provide decent user experience you need to be > able to present some results "sooner" than others. I would actually question whether this is really necessary. A few years back, I did a big literature review on metasearch, as well as a looked at a good number of usability studies that libraries did with metasearch systems. One thing that stood to me out was that the literature (written by librarians and technologists) was very concerned about the slow search times of metasearch, often seeing it as a deal-breaker. And yet, in the usability studies, actual students and faculty were far less concerned about the search times -- within reason, of course. I thought the UC Santa Cruz study [1] summarized the point well: "Users are willing to wait as long as they think that they will get useful results. Their perceptions of time depend on this belief." Trying to return the results of a metasearch quickly just for the sake of returning them quickly I think introduces other problems (in terms of relevance ranking and presentation) that do far more to negatively impact the user experience. Just my opinion, of course. --Dave [1] http://www.cdlib.org/services/d2d/metasearch/docs/core_ucsc_oct2004usability.pdf == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Kuba [skoc...@gmail.com] Sent: Tuesday, May 18, 2010 9:57 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts That is quite unfortunate, as we were looking at SRU 2.0 as a possible candidate for the front-end protocol for Index Data's pazpar2. The main problem with federate/broadcast/meta (however you want to call it ;) searching is that the back-end databases are scattered in different locations or simply slow in their response times and in order to provide decent user experience you need to be able to present some results "sooner" than others. Waiting for the slowest database to respond is usually not an option. On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress wrote: > On 18 May 2010 15:24, Ray Denenberg, Library of Congress > wrote: >> There is no synchronous operation in SRU. > > Sorry, meant to say "no asynchronous . > > --Ray > -- Cheers, Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
First, no. There are extensibility features in SRU but nothing that would help here. Actually, Jonathan, what I though you were suggesting was the creation of a (I hesitate to say it) metasearch engine. I use that term because it is what NISO called it, when they started their metasearch initiative five or so years ago, to create a standard for a metasearch engine, but they got distracted and the effort really came to nothing. The premise of the metasearch engine is that there exists a single-thread protocol, for example, SRU, and the need is to manage many threads, which is what the metasearch engine would have done if it had ever been defined. This is probably not an area for OASIS work, but if someone wanted to revive the effort in NISO (and put it on the right track) it could be useful. --Ray -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Tuesday, May 18, 2010 2:56 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts Jakub Skoczen wrote: > >> I wonder if someone, like Kuba, could design an 'extended async SRU' >> on top of SRU, that is very SRU like, but builds on top of it to add >> just enough operations for Kuba's use case area. I think that's the >> right way to approach it. >> > > Is there a particular "extensibility" feature in the protocol that > allows for this? > I don't know, but that's not what I was suggesting. I was suggesting you read the SRU spec, and then design your own "SRU-async" spec, which is defined as "exactly like SRU 2.0, except it also has the following operations, and is identified in an Explain document like X." Jonathan
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Jakub Skoczen wrote: I wonder if someone, like Kuba, could design an 'extended async SRU' on top of SRU, that is very SRU like, but builds on top of it to add just enough operations for Kuba's use case area. I think that's the right way to approach it. Is there a particular "extensibility" feature in the protocol that allows for this? I don't know, but that's not what I was suggesting. I was suggesting you read the SRU spec, and then design your own "SRU-async" spec, which is defined as "exactly like SRU 2.0, except it also has the following operations, and is identified in an Explain document like X." Jonathan
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
(in case you get confused by the change of signature: I've failed to notice sending previous posts under nick "Kuba", Jakub Skoczen is my full name) On Tue, May 18, 2010 at 8:20 PM, Jonathan Rochkind wrote: > I think the advantage is simplicity for the client, the client not having to > keep track of the different connections, the server does all that. Well, that and the fact that the server may perform some additional, on-the-fly processing on the retrieved results - eg. de-duplication or re-ranking. Surely, partial (async) responses may not have the quality of a complete, fully processed result but at least keep the user occupied during the process. > > But I think SRU makes the right choice in avoiding that for simplicity. > > I wonder if someone, like Kuba, could design an 'extended async SRU' on top > of SRU, that is very SRU like, but builds on top of it to add just enough > operations for Kuba's use case area. I think that's the right way to > approach it. Is there a particular "extensibility" feature in the protocol that allows for this? > > > > Ray Denenberg, Library of Congress wrote: >> >> What advantage do you see in having a "concurrent operations" feature >> (like >> Z39.50) versus opening several connections? >> >> (Concurrent operations introduced significant complexity into Z39.50 - >> including reference ids, operations, etc, and I'm not sure anyone ever >> really thought it was worth it.) >> >> --Ray >> >> -Original Message- >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of >> Kuba >> Sent: Tuesday, May 18, 2010 12:58 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts >> >> That is quite unfortunate, as we were looking at SRU 2.0 as a possible >> candidate for the front-end protocol for Index Data's pazpar2. The main >> problem with federate/broadcast/meta (however you want to call it >> ;) searching is that the back-end databases are scattered in different >> locations or simply slow in their response times and in order to provide >> decent user experience you need to be able to present some results >> "sooner" >> than others. Waiting for the slowest database to respond is usually not an >> option. >> >> On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress >> wrote: >> >>> >>> On 18 May 2010 15:24, Ray Denenberg, Library of Congress >>> wrote: >>> >>>> >>>> There is no synchronous operation in SRU. >>>> >>> >>> Sorry, meant to say "no asynchronous . >>> >>> --Ray >>> >>> >> >> >> >> > -- Cheers, Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
I think the advantage is simplicity for the client, the client not having to keep track of the different connections, the server does all that. But I think SRU makes the right choice in avoiding that for simplicity. I wonder if someone, like Kuba, could design an 'extended async SRU' on top of SRU, that is very SRU like, but builds on top of it to add just enough operations for Kuba's use case area. I think that's the right way to approach it. Ray Denenberg, Library of Congress wrote: What advantage do you see in having a "concurrent operations" feature (like Z39.50) versus opening several connections? (Concurrent operations introduced significant complexity into Z39.50 - including reference ids, operations, etc, and I'm not sure anyone ever really thought it was worth it.) --Ray -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Kuba Sent: Tuesday, May 18, 2010 12:58 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts That is quite unfortunate, as we were looking at SRU 2.0 as a possible candidate for the front-end protocol for Index Data's pazpar2. The main problem with federate/broadcast/meta (however you want to call it ;) searching is that the back-end databases are scattered in different locations or simply slow in their response times and in order to provide decent user experience you need to be able to present some results "sooner" than others. Waiting for the slowest database to respond is usually not an option. On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress wrote: On 18 May 2010 15:24, Ray Denenberg, Library of Congress wrote: There is no synchronous operation in SRU. Sorry, meant to say "no asynchronous . --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
What advantage do you see in having a "concurrent operations" feature (like Z39.50) versus opening several connections? (Concurrent operations introduced significant complexity into Z39.50 - including reference ids, operations, etc, and I'm not sure anyone ever really thought it was worth it.) --Ray -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Kuba Sent: Tuesday, May 18, 2010 12:58 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts That is quite unfortunate, as we were looking at SRU 2.0 as a possible candidate for the front-end protocol for Index Data's pazpar2. The main problem with federate/broadcast/meta (however you want to call it ;) searching is that the back-end databases are scattered in different locations or simply slow in their response times and in order to provide decent user experience you need to be able to present some results "sooner" than others. Waiting for the slowest database to respond is usually not an option. On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress wrote: > On 18 May 2010 15:24, Ray Denenberg, Library of Congress > > wrote: >> There is no synchronous operation in SRU. > > Sorry, meant to say "no asynchronous . > > --Ray > -- Cheers, Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
That is quite unfortunate, as we were looking at SRU 2.0 as a possible candidate for the front-end protocol for Index Data's pazpar2. The main problem with federate/broadcast/meta (however you want to call it ;) searching is that the back-end databases are scattered in different locations or simply slow in their response times and in order to provide decent user experience you need to be able to present some results "sooner" than others. Waiting for the slowest database to respond is usually not an option. On Tue, May 18, 2010 at 5:24 PM, Ray Denenberg, Library of Congress wrote: > On 18 May 2010 15:24, Ray Denenberg, Library of Congress > wrote: >> There is no synchronous operation in SRU. > > Sorry, meant to say "no asynchronous . > > --Ray > -- Cheers, Jakub
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
> What communities? I thought Peter Noerr, in the thread from last year, did a good job of explaining how "metasearch" and "federated search" have come to be adopted by different communities: http://www.mail-archive.com/code4lib@listserv.nd.edu/msg05188.html I agree that "broadcast search" and "aggregated index" are clear enough to distinguish between the two. But I suspect that "aggregated index" is a little too technical in its orientation. I don't see people outside of library programmers using that term. Instead even more vague and confusing terms like "discovery systems" seem to be making headway. --Dave == David Walker Library Web Services Manager California State University http://xerxes.calstate.edu From: Code for Libraries [code4...@listserv.nd.edu] On Behalf Of Mike Taylor [m...@indexdata.com] Sent: Tuesday, May 18, 2010 8:19 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts On 18 May 2010 15:52, Jonathan Rochkind wrote: > What terms do you suggest, Mike? "First, do no harm." The current situation with federated/meta/broadcast search is certainly unfortunate; but introducing yet a fourth term to mean the same thing is not going to make things better. > I think we're doomed no matter what [...] I think you should have finished your message there :-) > [...] with these, after certain communities > started to use "federated search" and "metasearch" in directly opposite > ways. What communities? Maybe we on the CODE4LIB list collectively carry enough weight that we could take the most prevalent meanings and propagate them? > I also was told recently that what is called an "accordion" in English is > called a "bandoneon" in Spanish, and what is called a "accordeon" in Spanish > is called a "bandoneon" in English. For what it's worth, and I say this as a fully paid-up Englishman, I have never heard of a bandoneon. > > Hope this helps. > > Mike Taylor wrote: >> >> On 18 May 2010 15:24, Ray Denenberg, Library of Congress >> wrote: >> >>> >>> There is no synchronous operation in SRU. >>> >>> As for federated search . >>> >>> To digress a moment, you may recall -- I believe it was on this list -- >>> there was discussion (maybe a year ago?) of what that even means and >>> whether >>> it is the same or differs from metasearch, whatever that means. That >>> discussion was inconclusive. Anyway, earlier drafts of SRU 2.0 describe >>> a >>> metasearch model. Recently, the committee decided that the terms >>> "metasearch" and "federated search" are undefined jargon. We now choose >>> to >>> call it "multi-server search". >>> >> >> Way to go. Introducting yet ANOTHER synonym can only help! >> >> (And don't forget "broadcast search".) >> >> > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
On 18 May 2010 16:29, Jonathan Rochkind wrote: > Mike Taylor wrote: >> >> What communities? > > All I know is we here on this very list had some people _insisting_ that > "federated search" _really_ meant aggregated index, and "meta search" > _really_ meant broadcast search, and other people insisting the opposite. > Both sides had citations to the literature. > > I'm uninterested in arguing about what words "really" mean. Clearly these > words have been used both ways in the profession and the literature. > > So I don't see any way around it by trying to find other words that attempt > be harder to use more than one way. As you can see, I like "broadcast > search" and "aggregated index". > >> Maybe we on the CODE4LIB list collectively carry >> enough weight that we could take the most prevalent meanings and >> propagate them? >> > > Ha, ha. Good luck with that. What we CAN do is spend a couple months > arguing about what the words REALLY mean on the list (we're good at that), > and then vote, and then have everyone else ignore the vote anyway. Ha, ha indeed. You are of course right. You're also right that "broadcast search" and "aggregated index" are both explicit terms not susceptible to misinterpretation. We should try to remember to use those instead. Sign me up! > > Jonathan > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Mike Taylor wrote: What communities? All I know is we here on this very list had some people _insisting_ that "federated search" _really_ meant aggregated index, and "meta search" _really_ meant broadcast search, and other people insisting the opposite. Both sides had citations to the literature. I'm uninterested in arguing about what words "really" mean. Clearly these words have been used both ways in the profession and the literature. So I don't see any way around it by trying to find other words that attempt be harder to use more than one way. As you can see, I like "broadcast search" and "aggregated index". Maybe we on the CODE4LIB list collectively carry enough weight that we could take the most prevalent meanings and propagate them? Ha, ha. Good luck with that. What we CAN do is spend a couple months arguing about what the words REALLY mean on the list (we're good at that), and then vote, and then have everyone else ignore the vote anyway. Jonathan
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
On 18 May 2010 15:24, Ray Denenberg, Library of Congress wrote: > There is no synchronous operation in SRU. Sorry, meant to say "no asynchronous . --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
On 18 May 2010 15:52, Jonathan Rochkind wrote: > What terms do you suggest, Mike? "First, do no harm." The current situation with federated/meta/broadcast search is certainly unfortunate; but introducing yet a fourth term to mean the same thing is not going to make things better. > I think we're doomed no matter what [...] I think you should have finished your message there :-) > [...] with these, after certain communities > started to use "federated search" and "metasearch" in directly opposite > ways. What communities? Maybe we on the CODE4LIB list collectively carry enough weight that we could take the most prevalent meanings and propagate them? > I also was told recently that what is called an "accordion" in English is > called a "bandoneon" in Spanish, and what is called a "accordeon" in Spanish > is called a "bandoneon" in English. For what it's worth, and I say this as a fully paid-up Englishman, I have never heard of a bandoneon. > > Hope this helps. > > Mike Taylor wrote: >> >> On 18 May 2010 15:24, Ray Denenberg, Library of Congress >> wrote: >> >>> >>> There is no synchronous operation in SRU. >>> >>> As for federated search . >>> >>> To digress a moment, you may recall -- I believe it was on this list -- >>> there was discussion (maybe a year ago?) of what that even means and >>> whether >>> it is the same or differs from metasearch, whatever that means. That >>> discussion was inconclusive. Anyway, earlier drafts of SRU 2.0 describe >>> a >>> metasearch model. Recently, the committee decided that the terms >>> "metasearch" and "federated search" are undefined jargon. We now choose >>> to >>> call it "multi-server search". >>> >> >> Way to go. Introducting yet ANOTHER synonym can only help! >> >> (And don't forget "broadcast search".) >> >> > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
What terms do you suggest, Mike? I think we're doomed no matter what with these, after certain communities started to use "federated search" and "metasearch" in directly opposite ways. I also was told recently that what is called an "accordion" in English is called a "bandoneon" in Spanish, and what is called a "accordeon" in Spanish is called a "bandoneon" in English. Hope this helps. Mike Taylor wrote: On 18 May 2010 15:24, Ray Denenberg, Library of Congress wrote: There is no synchronous operation in SRU. As for federated search . To digress a moment, you may recall -- I believe it was on this list -- there was discussion (maybe a year ago?) of what that even means and whether it is the same or differs from metasearch, whatever that means. That discussion was inconclusive. Anyway, earlier drafts of SRU 2.0 describe a metasearch model. Recently, the committee decided that the terms "metasearch" and "federated search" are undefined jargon. We now choose to call it "multi-server search". Way to go. Introducting yet ANOTHER synonym can only help! (And don't forget "broadcast search".)
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
On 18 May 2010 15:24, Ray Denenberg, Library of Congress wrote: > There is no synchronous operation in SRU. > > As for federated search . > > To digress a moment, you may recall -- I believe it was on this list -- > there was discussion (maybe a year ago?) of what that even means and whether > it is the same or differs from metasearch, whatever that means. That > discussion was inconclusive. Anyway, earlier drafts of SRU 2.0 describe a > metasearch model. Recently, the committee decided that the terms > "metasearch" and "federated search" are undefined jargon. We now choose to > call it "multi-server search". Way to go. Introducting yet ANOTHER synonym can only help! (And don't forget "broadcast search".)
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
There is no synchronous operation in SRU. As for federated search . To digress a moment, you may recall -- I believe it was on this list -- there was discussion (maybe a year ago?) of what that even means and whether it is the same or differs from metasearch, whatever that means. That discussion was inconclusive. Anyway, earlier drafts of SRU 2.0 describe a metasearch model. Recently, the committee decided that the terms "metasearch" and "federated search" are undefined jargon. We now choose to call it "multi-server search". So to answer the question of whether there is federated search support: yes, limited support, if by federated search you mean multi server search. There is no multi-server support in terms of separate result sets for different servers. However, for (1) faceted search results, and (2) subquery results, these can be grouped according to server. --Ray -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Kuba Sent: Tuesday, May 18, 2010 4:07 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts Hi, Does the current draft include any support for asynchronous operation of the protocol (either by status notifications and polling and/or streaming), e.g some chunk of results coming back before others? Sometime ago I read through an early draft published on the LOC site and it mentioned support for federated search but it's hard to imagine how could that be implemented without any async support.
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Hi,
Does the current draft include any support for asynchronous operation
of the protocol (either by status notifications and polling and/or
streaming), e.g some chunk of results coming back before others?
Sometime ago I read through an early draft published on the LOC site
and it mentioned support for federated search but it's hard to imagine
how could that be implemented without any async support.
On Tue, May 18, 2010 at 12:39 AM, Jonathan Rochkind wrote:
> Cool, we're on the same page.
>
> This means that the "asset" parameter not only does not need to be, but
> should NOT be, an actual parameterized value in the OpenSearch desc URL
> template, in contrast to Tony's current SRU-in-opensearch-extension draft
> spec.
>
> At least that's my argument. Seems pretty clear to me.
>
> Make sense:
>
> template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
>
> Does NOT make sense:
>
> template="http://my-sru-server.com?q={searchTerms}&accept={sru:accept}"/>
>
> [that parameter conflicts with the type in the Url template, does not make
> sense to be parameterized in the OpenSearch URL template. Whether it's
> parameterized to your SRU server is of no concern of OpenSearch, but to the
> extent it's in the URL, it has to be FIXED in the OpenSearch URL template.
> Is my argument. ]
>
>
>
> Ray Denenberg, Library of Congress wrote:
>>
>> "Rather, OpenSearch descriptions provide a _different URL template_ for
>> every response IANA content type available"
>>
>> Yes, of course, that's what I meant, I said it somewhat slopily, but in
>> many of the examples we've looked at, it comes down to the same thing, that
>> the different templates differ only in a single (hard-coded) parameter.
>>
>> --Ray
>>
>>
>> - Original Message - From: "Jonathan Rochkind"
>> To:
>> Sent: Monday, May 17, 2010 6:11 PM
>> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
>>
>>
>>
>>>
>>> Ray Denenberg, Library of Congress wrote:
>>>
>>>>
>>>> Ralph will probably be able to articulate this better than I can, but
>>>> the
>>>> accept parameter is driven by the requirement to be able to use
>>>> OpenSearch
>>>> (for example) to query an SRU server. The description document isn't
>>>> going
>>>> to provide templates that allow you to do this via content negotiation,
>>>> they
>>>> provide a parameter instead, to allow the client to tell the server that
>>>> it
>>>> wants, for example, an rss response.
>>>>
>>>>
>>>
>>> No, they don't. I am having this same debate with Tony Hammond.
>>>
>>> OpenSearch descriptions do NOT provide a parameter to allow the client to
>>> tell the server what response it wants. They also don't easily provide for
>>> content negotiation, it is true.
>>> Rather, OpenSearch descriptions provide a _different URL template_ for
>>> every response IANA content type available. Here is the example from the
>>> OpenSearch documentation:
>>>
>>> >> xmlns:example="http://example.com/opensearchextensions/1.0/";
>>>
>>> template="http://example.com?q={searchTerms}&c={example:color?}"/>
>>>
>>> Please note that application/rss+xml is an attribute of the URL template
>>> itself, it is NOT a parameter in the template.
>>>
>>> If SRU added an accept parameter to try and make OpenSearch happy, this
>>> is a big mistake, because it in fact _conflicts_ with OpenSearch desc -- to
>>> make it available as an actual parameter in the OpenSearch URL template.
>>>
>>> If on the other hand, you just want to hard-code it in though, that could
>>> make some sense.
>>>
>>> >> xmlns:example="http://example.com/opensearchextensions/1.0/";
>>>
>>>
>>> template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
>>>
>>> That might make sense, if that's the use case. But actually trying to
>>> provide a parameter for the _client_ to fill out in an OpenSearch desc in
>>> fact _conflicts_ with OpenSearch, for better or for worse the respones type
>>> is _hard coded_ into the template.
>>>
>>> Jonathan
>>>
>>>
>>>
>>>
>>>>
>>>> (I suggest, thou
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Cool, we're on the same page.
This means that the "asset" parameter not only does not need to be, but
should NOT be, an actual parameterized value in the OpenSearch desc URL
template, in contrast to Tony's current SRU-in-opensearch-extension
draft spec.
At least that's my argument. Seems pretty clear to me.
Make sense:
template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
Does NOT make sense:
template="http://my-sru-server.com?q={searchTerms}&accept={sru:accept}"/>
[that parameter conflicts with the type in the Url template, does not make
sense to be parameterized in the OpenSearch URL template. Whether it's
parameterized to your SRU server is of no concern of OpenSearch, but to the
extent it's in the URL, it has to be FIXED in the OpenSearch URL template. Is
my argument. ]
Ray Denenberg, Library of Congress wrote:
"Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available"
Yes, of course, that's what I meant, I said it somewhat slopily, but in many
of the examples we've looked at, it comes down to the same thing, that the
different templates differ only in a single (hard-coded) parameter.
--Ray
- Original Message -
From: "Jonathan Rochkind"
To:
Sent: Monday, May 17, 2010 6:11 PM
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Ray Denenberg, Library of Congress wrote:
Ralph will probably be able to articulate this better than I can, but the
accept parameter is driven by the requirement to be able to use
OpenSearch
(for example) to query an SRU server. The description document isn't
going
to provide templates that allow you to do this via content negotiation,
they
provide a parameter instead, to allow the client to tell the server that
it
wants, for example, an rss response.
No, they don't. I am having this same debate with Tony Hammond.
OpenSearch descriptions do NOT provide a parameter to allow the client to
tell the server what response it wants. They also don't easily provide for
content negotiation, it is true.
Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available. Here is the example from the
OpenSearch documentation:
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://example.com?q={searchTerms}&c={example:color?}"/>
Please note that application/rss+xml is an attribute of the URL template
itself, it is NOT a parameter in the template.
If SRU added an accept parameter to try and make OpenSearch happy, this is
a big mistake, because it in fact _conflicts_ with OpenSearch desc --
to make it available as an actual parameter in the OpenSearch URL
template.
If on the other hand, you just want to hard-code it in though, that could
make some sense.
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
That might make sense, if that's the use case. But actually trying to
provide a parameter for the _client_ to fill out in an OpenSearch desc in
fact _conflicts_ with OpenSearch, for better or for worse the respones
type is _hard coded_ into the template.
Jonathan
(I suggest, though, that you move further discussion of this to the SRU
list.)
--Ray
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
Robert Sanderson
Sent: Monday, May 17, 2010 3:44 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
In today's RESTful world, what's the requirement for the httpAccept
parameter? Isn't straight content negotiation sufficient rather than
pulling the headers into the URI?
What happens if the accept header and the httpAccept parameter say
different
things?
Rob
On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph wrote:
I'd code it. (I have already coded to it.) For me, the httpAccept
parameter and support for content negotiation on responses is a
wonderful addition to the standard. It lets us be OpenSearch compliant
finally.
The virtue of coding to the draft is that there's a chance we can fix
any problems you encounter. While we consider the draft stable, that
doesn't mean everything has been tested in the real world. I'm
particularly nervous about the facets support I championed. I asked for
it to support users of my SRW server framework who wanted to create an
interface to SOLR. Those users disappeared and the usability of the SRU
interface is untested.
Ralph
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf
Of
Jona
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
"Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available"
Yes, of course, that's what I meant, I said it somewhat slopily, but in many
of the examples we've looked at, it comes down to the same thing, that the
different templates differ only in a single (hard-coded) parameter.
--Ray
- Original Message -
From: "Jonathan Rochkind"
To:
Sent: Monday, May 17, 2010 6:11 PM
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Ray Denenberg, Library of Congress wrote:
Ralph will probably be able to articulate this better than I can, but the
accept parameter is driven by the requirement to be able to use
OpenSearch
(for example) to query an SRU server. The description document isn't
going
to provide templates that allow you to do this via content negotiation,
they
provide a parameter instead, to allow the client to tell the server that
it
wants, for example, an rss response.
No, they don't. I am having this same debate with Tony Hammond.
OpenSearch descriptions do NOT provide a parameter to allow the client to
tell the server what response it wants. They also don't easily provide for
content negotiation, it is true.
Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available. Here is the example from the
OpenSearch documentation:
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://example.com?q={searchTerms}&c={example:color?}"/>
Please note that application/rss+xml is an attribute of the URL template
itself, it is NOT a parameter in the template.
If SRU added an accept parameter to try and make OpenSearch happy, this is
a big mistake, because it in fact _conflicts_ with OpenSearch desc --
to make it available as an actual parameter in the OpenSearch URL
template.
If on the other hand, you just want to hard-code it in though, that could
make some sense.
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
That might make sense, if that's the use case. But actually trying to
provide a parameter for the _client_ to fill out in an OpenSearch desc in
fact _conflicts_ with OpenSearch, for better or for worse the respones
type is _hard coded_ into the template.
Jonathan
(I suggest, though, that you move further discussion of this to the SRU
list.)
--Ray
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
Robert Sanderson
Sent: Monday, May 17, 2010 3:44 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
In today's RESTful world, what's the requirement for the httpAccept
parameter? Isn't straight content negotiation sufficient rather than
pulling the headers into the URI?
What happens if the accept header and the httpAccept parameter say
different
things?
Rob
On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph wrote:
I'd code it. (I have already coded to it.) For me, the httpAccept
parameter and support for content negotiation on responses is a
wonderful addition to the standard. It lets us be OpenSearch compliant
finally.
The virtue of coding to the draft is that there's a chance we can fix
any problems you encounter. While we consider the draft stable, that
doesn't mean everything has been tested in the real world. I'm
particularly nervous about the facets support I championed. I asked for
it to support users of my SRW server framework who wanted to create an
interface to SOLR. Those users disappeared and the usability of the SRU
interface is untested.
Ralph
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf
Of
Jonathan Rochkind
Sent: Monday, May 17, 2010 3:18 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current
drafts
Wait, I'm so confused. Is SRU 2.0 actually a published standard, or
are
you just showing us a work in progress that nobody should be writing
code to yet?
I'm confused because I thought it was just a draft work in progress,
but
then you talk about official vs unofficial copies... an unofficial
copy
of a draft work in progress that isn't a spec yet anyway? Very
confused.
If I'm planning on writing software to SRU... do you recommend I use
the
(until now not publically available so I didn't have a choice)
"unofficial" SRU 2.0 thing, or is that still just a draft work in
progress nobody should be writing software to yet?
Jonathan
Ray Denenberg, Library of Congress wrote:
For those of you who have recently asked about current OASIS drafts
of SRU
(2.0) and CQL ...
The *
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Ray Denenberg, Library of Congress wrote:
Ralph will probably be able to articulate this better than I can, but the
accept parameter is driven by the requirement to be able to use OpenSearch
(for example) to query an SRU server. The description document isn't going
to provide templates that allow you to do this via content negotiation, they
provide a parameter instead, to allow the client to tell the server that it
wants, for example, an rss response.
No, they don't. I am having this same debate with Tony Hammond.
OpenSearch descriptions do NOT provide a parameter to allow the client
to tell the server what response it wants. They also don't easily
provide for content negotiation, it is true.
Rather, OpenSearch descriptions provide a _different URL template_ for
every response IANA content type available. Here is the example from
the OpenSearch documentation:
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://example.com?q={searchTerms}&c={example:color?}"/>
Please note that application/rss+xml is an attribute of the URL template
itself, it is NOT a parameter in the template.
If SRU added an accept parameter to try and make OpenSearch happy, this
is a big mistake, because it in fact _conflicts_ with OpenSearch desc --
to make it available as an actual parameter in the OpenSearch URL template.
If on the other hand, you just want to hard-code it in though, that
could make some sense.
xmlns:example="http://example.com/opensearchextensions/1.0/";
template="http://my-sru-server.com?q={searchTerms}&accept=application%2Frss"/>
That might make sense, if that's the use case. But actually trying to
provide a parameter for the _client_ to fill out in an OpenSearch desc
in fact _conflicts_ with OpenSearch, for better or for worse the
respones type is _hard coded_ into the template.
Jonathan
(I suggest, though, that you move further discussion of this to the SRU
list.)
--Ray
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of
Robert Sanderson
Sent: Monday, May 17, 2010 3:44 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
In today's RESTful world, what's the requirement for the httpAccept
parameter? Isn't straight content negotiation sufficient rather than
pulling the headers into the URI?
What happens if the accept header and the httpAccept parameter say different
things?
Rob
On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph wrote:
I'd code it. (I have already coded to it.) For me, the httpAccept
parameter and support for content negotiation on responses is a
wonderful addition to the standard. It lets us be OpenSearch
compliant finally.
The virtue of coding to the draft is that there's a chance we can fix
any problems you encounter. While we consider the draft stable, that
doesn't mean everything has been tested in the real world. I'm
particularly nervous about the facets support I championed. I asked
for it to support users of my SRW server framework who wanted to
create an interface to SOLR. Those users disappeared and the
usability of the SRU interface is untested.
Ralph
-Original Message-
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf
Of
Jonathan Rochkind
Sent: Monday, May 17, 2010 3:18 PM
To: CODE4LIB@LISTSERV.ND.EDU
Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current
drafts
Wait, I'm so confused. Is SRU 2.0 actually a published standard, or
are
you just showing us a work in progress that nobody should be writing
code to yet?
I'm confused because I thought it was just a draft work in progress,
but
then you talk about official vs unofficial copies... an unofficial
copy
of a draft work in progress that isn't a spec yet anyway? Very
confused.
If I'm planning on writing software to SRU... do you recommend I use
the
(until now not publically available so I didn't have a choice)
"unofficial" SRU 2.0 thing, or is that still just a draft work in
progress nobody should be writing software to yet?
Jonathan
Ray Denenberg, Library of Congress wrote:
For those of you who have recently asked about current OASIS drafts
of SRU
(2.0) and CQL ...
The *official* versions reside at OASIS, but because of confusing
(and
sometimes inaccessible) links, as well as uncertainty about status
(because of imbedded dates), we now maintain *unofficial copies*
of
the
most current versions at:
http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc
http://www.loc.gov/standards/sru/oasis/current/cql.doc
We will continue to maintain copies of the most current version at
these
URLs.
--Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
"In today's RESTful world, what's the requirement for the httpAccept parameter? " Ralph will probably be able to articulate this better than I can, but the accept parameter is driven by the requirement to be able to use OpenSearch (for example) to query an SRU server. The description document isn't going to provide templates that allow you to do this via content negotiation, they provide a parameter instead, to allow the client to tell the server that it wants, for example, an rss response. (I suggest, though, that you move further discussion of this to the SRU list.) --Ray -Original Message- From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Robert Sanderson Sent: Monday, May 17, 2010 3:44 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts In today's RESTful world, what's the requirement for the httpAccept parameter? Isn't straight content negotiation sufficient rather than pulling the headers into the URI? What happens if the accept header and the httpAccept parameter say different things? Rob On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph wrote: > I'd code it. (I have already coded to it.) For me, the httpAccept > parameter and support for content negotiation on responses is a > wonderful addition to the standard. It lets us be OpenSearch > compliant finally. > > The virtue of coding to the draft is that there's a chance we can fix > any problems you encounter. While we consider the draft stable, that > doesn't mean everything has been tested in the real world. I'm > particularly nervous about the facets support I championed. I asked > for it to support users of my SRW server framework who wanted to > create an interface to SOLR. Those users disappeared and the > usability of the SRU interface is untested. > > Ralph > >> -Original Message- >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf > Of >> Jonathan Rochkind >> Sent: Monday, May 17, 2010 3:18 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current > drafts >> >> Wait, I'm so confused. Is SRU 2.0 actually a published standard, or > are >> you just showing us a work in progress that nobody should be writing >> code to yet? >> >> I'm confused because I thought it was just a draft work in progress, > but >> then you talk about official vs unofficial copies... an unofficial > copy >> of a draft work in progress that isn't a spec yet anyway? Very > confused. >> >> If I'm planning on writing software to SRU... do you recommend I use > the >> (until now not publically available so I didn't have a choice) >> "unofficial" SRU 2.0 thing, or is that still just a draft work in >> progress nobody should be writing software to yet? >> >> Jonathan >> >> Ray Denenberg, Library of Congress wrote: >> > For those of you who have recently asked about current OASIS drafts > of SRU >> > (2.0) and CQL ... >> > >> > The *official* versions reside at OASIS, but because of confusing > (and >> > sometimes inaccessible) links, as well as uncertainty about status >> > (because of imbedded dates), we now maintain *unofficial copies* >> > of > the >> > most current versions at: >> > >> > http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc >> > http://www.loc.gov/standards/sru/oasis/current/cql.doc >> > >> > We will continue to maintain copies of the most current version at > these >> > URLs. >> > >> > --Ray >> > >> > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
The SRU listserv is a public list for discussion of SRU, with no connection to OASIS. See http://www.loc.gov/standards/sru/community/listserv.html --Ray - Original Message - From: "Jonathan Rochkind" To: Sent: Monday, May 17, 2010 3:45 PM Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts I believe last I heard the SRU list was a private list that you had to be a member of OASIS and on the SRU committee to access. If that is no longer the case, then please do send me instructions on how to join this list, I would very much like to see what's going on in SRU. If you want people in the larger world to keep up with this stuff, you have to start doing it in less secretive means. I would very much like to be on the SRU list, but I am not willing to join any committees or be on any conference calls. Jonathan Ray Denenberg, Library of Congress wrote: Sorry for any confusion. SRU 2.0 is not a published standard, it is currently a work in progress. (Whether you should be writing code to it is a question that I suggest you take to the SRU list. The draft is mature enough now that it is a reasonable question to discuss. There are people writing code to it.) OASIS wants to be sure that official copies (and they use that term, "official", whether referring to an approved spec or a draft) reside on their server. So the copies at LC must be called *unofficial copies* of the draft (or the spec, when it becomes approved). Again, sorry for the confusion. --Ray - Original Message - From: "Jonathan Rochkind" To: Sent: Monday, May 17, 2010 3:17 PM Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts Wait, I'm so confused. Is SRU 2.0 actually a published standard, or are you just showing us a work in progress that nobody should be writing code to yet? I'm confused because I thought it was just a draft work in progress, but then you talk about official vs unofficial copies... an unofficial copy of a draft work in progress that isn't a spec yet anyway? Very confused. If I'm planning on writing software to SRU... do you recommend I use the (until now not publically available so I didn't have a choice) "unofficial" SRU 2.0 thing, or is that still just a draft work in progress nobody should be writing software to yet? Jonathan Ray Denenberg, Library of Congress wrote: For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Also, if there's any documentation on "what's changed" between 1.2 and 2.0 for SRU and CQL, that would be useful. Those specs themselves are awfully long and dense, to skim through tryign to figure out what's changed. Ray Denenberg, Library of Congress wrote: For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
I believe last I heard the SRU list was a private list that you had to be a member of OASIS and on the SRU committee to access. If that is no longer the case, then please do send me instructions on how to join this list, I would very much like to see what's going on in SRU. If you want people in the larger world to keep up with this stuff, you have to start doing it in less secretive means. I would very much like to be on the SRU list, but I am not willing to join any committees or be on any conference calls. Jonathan Ray Denenberg, Library of Congress wrote: Sorry for any confusion. SRU 2.0 is not a published standard, it is currently a work in progress. (Whether you should be writing code to it is a question that I suggest you take to the SRU list. The draft is mature enough now that it is a reasonable question to discuss. There are people writing code to it.) OASIS wants to be sure that official copies (and they use that term, "official", whether referring to an approved spec or a draft) reside on their server. So the copies at LC must be called *unofficial copies* of the draft (or the spec, when it becomes approved). Again, sorry for the confusion. --Ray - Original Message - From: "Jonathan Rochkind" To: Sent: Monday, May 17, 2010 3:17 PM Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts Wait, I'm so confused. Is SRU 2.0 actually a published standard, or are you just showing us a work in progress that nobody should be writing code to yet? I'm confused because I thought it was just a draft work in progress, but then you talk about official vs unofficial copies... an unofficial copy of a draft work in progress that isn't a spec yet anyway? Very confused. If I'm planning on writing software to SRU... do you recommend I use the (until now not publically available so I didn't have a choice) "unofficial" SRU 2.0 thing, or is that still just a draft work in progress nobody should be writing software to yet? Jonathan Ray Denenberg, Library of Congress wrote: For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
In today's RESTful world, what's the requirement for the httpAccept parameter? Isn't straight content negotiation sufficient rather than pulling the headers into the URI? What happens if the accept header and the httpAccept parameter say different things? Rob On Mon, May 17, 2010 at 1:37 PM, LeVan,Ralph wrote: > I'd code it. (I have already coded to it.) For me, the httpAccept > parameter and support for content negotiation on responses is a > wonderful addition to the standard. It lets us be OpenSearch compliant > finally. > > The virtue of coding to the draft is that there's a chance we can fix > any problems you encounter. While we consider the draft stable, that > doesn't mean everything has been tested in the real world. I'm > particularly nervous about the facets support I championed. I asked for > it to support users of my SRW server framework who wanted to create an > interface to SOLR. Those users disappeared and the usability of the SRU > interface is untested. > > Ralph > >> -Original Message- >> From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf > Of >> Jonathan Rochkind >> Sent: Monday, May 17, 2010 3:18 PM >> To: CODE4LIB@LISTSERV.ND.EDU >> Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current > drafts >> >> Wait, I'm so confused. Is SRU 2.0 actually a published standard, or > are >> you just showing us a work in progress that nobody should be writing >> code to yet? >> >> I'm confused because I thought it was just a draft work in progress, > but >> then you talk about official vs unofficial copies... an unofficial > copy >> of a draft work in progress that isn't a spec yet anyway? Very > confused. >> >> If I'm planning on writing software to SRU... do you recommend I use > the >> (until now not publically available so I didn't have a choice) >> "unofficial" SRU 2.0 thing, or is that still just a draft work in >> progress nobody should be writing software to yet? >> >> Jonathan >> >> Ray Denenberg, Library of Congress wrote: >> > For those of you who have recently asked about current OASIS drafts > of SRU >> > (2.0) and CQL ... >> > >> > The *official* versions reside at OASIS, but because of confusing > (and >> > sometimes inaccessible) links, as well as uncertainty about status >> > (because of imbedded dates), we now maintain *unofficial copies* of > the >> > most current versions at: >> > >> > http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc >> > http://www.loc.gov/standards/sru/oasis/current/cql.doc >> > >> > We will continue to maintain copies of the most current version at > these >> > URLs. >> > >> > --Ray >> > >> > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
I'd code it. (I have already coded to it.) For me, the httpAccept parameter and support for content negotiation on responses is a wonderful addition to the standard. It lets us be OpenSearch compliant finally. The virtue of coding to the draft is that there's a chance we can fix any problems you encounter. While we consider the draft stable, that doesn't mean everything has been tested in the real world. I'm particularly nervous about the facets support I championed. I asked for it to support users of my SRW server framework who wanted to create an interface to SOLR. Those users disappeared and the usability of the SRU interface is untested. Ralph > -Original Message- > From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of > Jonathan Rochkind > Sent: Monday, May 17, 2010 3:18 PM > To: CODE4LIB@LISTSERV.ND.EDU > Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts > > Wait, I'm so confused. Is SRU 2.0 actually a published standard, or are > you just showing us a work in progress that nobody should be writing > code to yet? > > I'm confused because I thought it was just a draft work in progress, but > then you talk about official vs unofficial copies... an unofficial copy > of a draft work in progress that isn't a spec yet anyway? Very confused. > > If I'm planning on writing software to SRU... do you recommend I use the > (until now not publically available so I didn't have a choice) > "unofficial" SRU 2.0 thing, or is that still just a draft work in > progress nobody should be writing software to yet? > > Jonathan > > Ray Denenberg, Library of Congress wrote: > > For those of you who have recently asked about current OASIS drafts of SRU > > (2.0) and CQL ... > > > > The *official* versions reside at OASIS, but because of confusing (and > > sometimes inaccessible) links, as well as uncertainty about status > > (because of imbedded dates), we now maintain *unofficial copies* of the > > most current versions at: > > > > http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc > > http://www.loc.gov/standards/sru/oasis/current/cql.doc > > > > We will continue to maintain copies of the most current version at these > > URLs. > > > > --Ray > > > >
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Sorry for any confusion. SRU 2.0 is not a published standard, it is currently a work in progress. (Whether you should be writing code to it is a question that I suggest you take to the SRU list. The draft is mature enough now that it is a reasonable question to discuss. There are people writing code to it.) OASIS wants to be sure that official copies (and they use that term, "official", whether referring to an approved spec or a draft) reside on their server. So the copies at LC must be called *unofficial copies* of the draft (or the spec, when it becomes approved). Again, sorry for the confusion. --Ray - Original Message - From: "Jonathan Rochkind" To: Sent: Monday, May 17, 2010 3:17 PM Subject: Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts Wait, I'm so confused. Is SRU 2.0 actually a published standard, or are you just showing us a work in progress that nobody should be writing code to yet? I'm confused because I thought it was just a draft work in progress, but then you talk about official vs unofficial copies... an unofficial copy of a draft work in progress that isn't a spec yet anyway? Very confused. If I'm planning on writing software to SRU... do you recommend I use the (until now not publically available so I didn't have a choice) "unofficial" SRU 2.0 thing, or is that still just a draft work in progress nobody should be writing software to yet? Jonathan Ray Denenberg, Library of Congress wrote: For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
Re: [CODE4LIB] OASIS SRU and CQL, access to most-current drafts
Wait, I'm so confused. Is SRU 2.0 actually a published standard, or are you just showing us a work in progress that nobody should be writing code to yet? I'm confused because I thought it was just a draft work in progress, but then you talk about official vs unofficial copies... an unofficial copy of a draft work in progress that isn't a spec yet anyway? Very confused. If I'm planning on writing software to SRU... do you recommend I use the (until now not publically available so I didn't have a choice) "unofficial" SRU 2.0 thing, or is that still just a draft work in progress nobody should be writing software to yet? Jonathan Ray Denenberg, Library of Congress wrote: For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
[CODE4LIB] OASIS SRU and CQL, access to most-current drafts
For those of you who have recently asked about current OASIS drafts of SRU (2.0) and CQL ... The *official* versions reside at OASIS, but because of confusing (and sometimes inaccessible) links, as well as uncertainty about status (because of imbedded dates), we now maintain *unofficial copies* of the most current versions at: http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc http://www.loc.gov/standards/sru/oasis/current/cql.doc We will continue to maintain copies of the most current version at these URLs. --Ray
