OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Mike Taylor message (1)


This is one of two messages from Mike Taylor. (Second to follow.)  Feel free
to respond, on the SRU list. (It would be good if someone other than me
responds.)

--Ray

----- Original Message ----- 
From: "Mike Taylor" <mike@INDEXDATA.COM>
To: <ZNG@LISTSERV.LOC.GOV>
Sent: Thursday, August 28, 2008 7:25 AM
Subject: SRU/CQL 2.0: Invitation to participate in OASIS SWS TC Development


> Really?  It's hard for me to see how this is a good idea.  Surely our
> problem at the moment is how to improve take-up of SRU as it currently
> exists -- immediately leaping ahead and making another new one,
> different again, seems like an own goal, and smells suspiciously like
> making more work for the sake of it.  Not to mention bringing the
> resulting protocol yet closer to the Z39.50 it was deliberately
> designed to simplify.
>
>  _/|_ ___________________________________________________________________
> /o ) \/  Mike Taylor    <mike@indexdata.com>
http://www.miketaylor.org.uk
> )_v__/\  "Man is an exception, whatever else he is.  If it is not true
> that a divine being fell, then we can only say that one of the
> animals went entirely off its head" -- G. K. Chesterton.
>
>
>
>
> Ray Denenberg, Library of Congress writes:
>  > 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]