Draft OpenSearch Extension for SRU

[Tony Hammond]

Hi:

We would like to put out to the list here a draft OpenSearch Extension
for SRU for review:

http://nurture.nature.com/opensearch/sru/

This is very much an early draft and we would appreciate any feedback.
This is aligned with the latest (Oct. 19) SRU 2.0 public draft and
includes all the request parameters.

An SRU Extension would be a key step in OpenSearch/SRU alignment, not
least because we now have SRU implementations which are OpenSearch
addressable.

The draft is reasonably complete but might benefit from some
additional explanatory text up front.

Some issues:

1. License. This draft (following other examples) states that:

"This document is made available subject to the terms of the
Creative Commons Attribution-ShareAlike 2.5 License."

Are we OK with that, or do we need another license?

2. Namespace. I just followed current OpenSearch usage and put a
namespace as

http://a9.com/-/opensearch/extensions/sru/2.0/

Again, are we OK with that, or do we want another namespace?

3. Format. For demo purposes I'm using the OpenSearch doc
template. I would hope that we can go ahead with this format and
register the document to appear in the standard OpenSearch extension
directory:

http://www.opensearch.org/Specifications/OpenSearch/Extensions

4. Parameters. I have marked the following parameters as
deprecated since they are synonyms for OpenSearch parameters:

* sru:query [ = "searchTerms" ]

* sru:startRecords [ = "startIndex" ]

* sru:maximumRecords [ = "count" ]

Maybe there's a better way to handle this? Parameters are
introduced in same order as presented in the SRU specs, but maybe
these could be relegated to a "Legacy Parameters" section or similar?

This really is where OpenSearch and SRU are treading on each
other's toes. But this is spec is aimed at sending an SRU query via
OpenSearch.

I also don't know if the spec as a whole is too long. Would it be
better just to sumarize the parameters, cut back on the examples, and
refer readers to the SRU specs?

Looking for your feedback.

Cheers,

Tony

[DeWitt Clinton]

This is fantastic, thank you, Tony.

I'll respond more in detail in a bit -- about to launch something myself -- but in the meantime, please feel free to move anything you like over to the opensearch.org website (the path you suggest sounds perfect).  If you need additional access permissions, please let me know.

-DeWitt

--

You received this message because you are subscribed to the Google Groups "OpenSearch" group.
To post to this group, send email to opens...@googlegroups.com.
To unsubscribe from this group, send email to opensearch+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensearch?hl=.

[Tony Hammond]

Hi DeWitt:

Thanks for that invite to add in our proposal. I thus went ahead and
added the draft proposal for the SRU extension to the site. I added
this under "Extension proposals from the Community", but was a little
unclear as to the proper division between the extensions, see below:

==

Draft extension specifications

* OpenSearch Referrer extension
* OpenSearch Relevance extension
* OpenSearch Parameter extension
* OpenSearch Suggestions extension
* OpenSearch Geo extension (Draft)
* OpenSearch Time extension (Draft)

Extension proposals from the Community

* OpenSearch Advertisement extension (Draft)
* OpenSearch Commerce extension (Draft)
* OpenSearch Mobile extension (Draft)
* OpenSearch Spelling extension (Draft)
* OpenSearch SRU extension (Draft)

==

Also I note that on the home page the Draft extension specifications
are specifically listed and not the Community proposals and that the
Draft extensions are not updated (e.g. Geo is listed and Time is not,
and also Geo is listed ahead of the other extensions, e.g. Referrer,
Relevance, etc.). Am wondering if that page should be updated to
either list all extensions or to explicitly link to both the Draft
extensions *and* the Community proposals and not list the Draft
extensions as such.

I think we are good with the proposed namespace (as long as that is
acceptable to the Community) and also the license terms.

I removed the wording about deprecating three of the SRU parameters
(which I only intended to be "deprecated" within an OpenSearch
context) and instead left the implementation note about not using
these parameters (or using advisedly) within an OpenSearch template.

Perhaps I should add one or sentences by way of introduction to SRU,
and also there is still some flux in terms of the final SRU 2.0
parameter set. Hence this proposal is marked "Draft".

We would still welcome any feedback on developing this further.

Cheers,

Tony

On Nov 17, 4:52 pm, DeWitt Clinton <dew...@unto.net> wrote:
> This is fantastic, thank you, Tony.
>
> I'll respond more in detail in a bit -- about to launch something myself --
> but in the meantime, please feel free to move anything you like over to the
> opensearch.org website (the path you suggest sounds perfect).  If you need
> additional access permissions, please let me know.
>
> -DeWitt
>

> > opensearch+...@googlegroups.com<opensearch%2Bunsu...@googlegroups.com>
> > .

[DeWitt Clinton]

Thanks again, Tony.  This is great.

I'll admit that the process for adding new specs is perhaps overly ad-hoc right now.  But I completely agree that the distinction between "community" extensions and otherwise is ambiguous and unclear.  Not sure the best way to clean that up really, but I agree that we should probably just update the homepage to list all of the extensions, since it is a small enough list and we want to maximize exposure to encourage reuse.  I've gone ahead and done that now.

As an aside, I'd say that at this point OpenSearch is all "community," which is a fine thing in my opinion.

Regarding licensing, since this is a new spec you may want to use the current Creative Commons 3.0 BY or BY-SA license instead of the older 2.5 license, which was the latest at the time the original spec was authored.  Personally I prefer BY these days, but ultimately it should be up to the authors (unless we want to try as a community to offer more rigid guidance).

Or, if you want to try something new, the Open Web Foundation Agreement (http://openwebfoundation.org/legal/) was designed for just this sort of effort.  In fact, I eventually intend to track down the copyright and trademark holders on OpenSearch (Amazon.com, mostly) and ask if they mind if we retroactively apply the OWF agreement to the OpenSearch spec.  The advantage of the OWF agreement over the CC license is that the OWFa explicitly covers downstream implementor rights with respect to patents, not just copyright.  (Disclosure: I had a hand in authoring the OWF agreement.)

-DeWitt

To unsubscribe from this group, send email to opensearch+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/opensearch?hl=en.

[Tim Williams]

I *still*[1] think overloading normal HTTP headers is a bad idea and
unnecessary. Since OpenSearch was used to justify its inclusion
before, perhaps someone here could shed some light on it? It seems to
me normal HTTP Conneg is sufficient. If implementations want to put
different result representations behind different URIs then they could
simply add another Url element with a @type hint.

Thanks,
--tim

[1] - http://lists.oasis-open.org/archives/search-ws-comment/200908/threads.html

[Ray Denenberg]

From: "Tim Williams" <willi...@gmail.com>

>
> I *still*[1] think overloading normal HTTP headers is a bad idea and
> unnecessary. Since OpenSearch was used to justify its inclusion
> before, perhaps someone here could shed some light on it?

For context here, the discussion Tim refers to actually happened on a
different list, the OASIS Search-ws-comment list. You can see that thread
beginning at
http://lists.oasis-open.org/archives/search-ws-comment/200908/msg00000.html

I invite folks on this list to read that discussion and continue it here.

--Ray Denenberg