Fw: SRU/CQL 2.0: Invitation to participate in OASIS SWS TC Development

["Ray Denenberg" <raydenenberg@starpower.net>]

I don't know if everyone here is subscribed to the SRU list. Here is one of
the messages I posted.  (Second to follow). --Ray

----- Original Message ----- 
From: "Ray Denenberg, Library of Congress" <rden@loc.gov>
To: <ZNG@sun8.LOC.GOV>
Sent: Wednesday, August 27, 2008 2:42 PM
Subject: SRU/CQL 2.0: Invitation to participate in OASIS SWS TC Development


> SRU Implementors:
>
> The OASIS Search Web Services Technical Committee (SWS TC) invites your
> participation in the development of SRU/CQL 2.0.
>
> We have begun accumulating suggestions for 2.0 features; additional
> suggestions are welcome.  We are also currently gathering requirements for
> geospatial  and LOM applications.
>
>  Among the suggested 2.0 features are:
>
> 1. Allow Non-XML Record Representations
> Many formats do not map easily into XML, for example multimedia, images,
and
> even complex text formats. The suggestion is to allow non-xml serialized
> data in the response, as well as value by reference. These would be
signaled
> by additional values for the recordPacking parameter. For example
> recordPacking="base64" or recordPacking="uri".
>
> 2. Proximity
>  deprecate the PROX BOOLEAN operator and instead represent proximity by
two
> methods:
>
>  -- Adding a relation: 'window'.
> examples:
>  * dc.title window/distance<5/unit=word "fries salt vinegar"
>   (fries, salt, and vinegar all within a span of 5 words)
>  *dc.title window/distance<5/unit=word ((fish and fries) and (salt or
> vinegar))
>  (fish and chips and one of salt or vinegar, in a 5 word window)
>  * dc.title window/distance=2/unit=word/ordered "fries salt "
>  (fries followed by salt with 2 words between)
>
> -- Adding a boolean modifier 'prox' which acts the same as the current
> boolean, however can be attached to either AND (the current style of
> proximity) or  NOT for negative proximity.
> Example:
> * "fish and" not/prox chips
>    ("fish and" followed by anything other than chips)
>
>
>
> 3. Faceted Searching ("scan" a result set)
> One might search a library database for books about a particular topic,
and
> then see how many records there are in different time period
>
>
> 4. Result Set Size
> Allow the client to indicate how much effort the server should take to
> determine or estimate the number of records in the result set. Similarly,
> allow the response to estimate accuracy of  the result-set-size reported.
> The server may be able to determine the exact number of records, or
provide
> a realistic estimate, but it may be an expensive process. The server might
> prefer not go through that process unless the client requests that it does
> so. Or the client might want to explicitly request that the server go
> through, or not go through, that process. The client might want the first
10
> records, or any 10 records, regardless of how many records there are. In
> that case if the server goes through the process of determining how many
> records there are, it may go through an expensive process for nothing.
There
> is also the special case where the server cannot determine or estimate the
> number of records in the result set. In that case it might be useful to
have
> a special value or some way to indicate this condition.
>
>
> 5. Multiple Query Types
> CQL is currently the only query type used by SRU but there could be other
> query types as well, for example, Parameterized Query and XQuery.
>
>
> 6.  Eliminate the Version and Operation Parameters
> These two parameters  are based on the assumption that the same base URL
> might be used for different operations and versions. Instead, different
base
> URLs should be used.
>
>
> 7. Alternative Response Formats
> Allow the client to request that the response be supplied in a specific
> format, for example ATOM.
>
>
> ********
>
> We invite those interested in the development of 2.0 to join the
committee.
> However all of these (and further) proposed features will be discussed on
> this list, as well as on the public OASIS listserv for the Committee.  So
if
> you are unable to join the committee there is still ample opportunity to
> participate.
>
> Rob Sanderson will be the lead Technical Committee member for this 2.0
> activity.
>
> --Ray Denenberg