Re: [search-ws] proposals page

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Might it also be useful to have a request parameter to indicate what facets
are desired?

----- Original Message ----- 
From: "Janifer Gatenby" <Janifer.Gatenby@oclc.org>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>;
<search-ws@lists.oasis-open.org>
Sent: Tuesday, October 14, 2008 8:21 AM
Subject: RE: [search-ws] proposals page


My second choice would be a new element in search response,

Janifer

-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: 14 October 2008 14:07
To: search-ws@lists.oasis-open.org
Subject: Re: [search-ws] proposals page

Is there demand for  faceted search?  My impression is yes, and if so,
the suggestion to solve it via extension seems contrary to our process.
The premise of "extra data", or at least one premise, is articuated in
http://www.loc.gov/standards/sru/specs/extra-data.html  which says:

"It is expected that if there is sufficient demand for a particular
piece of additional information, that piece of information will be
migrated into the protocol in a later version."

If we are not going to "mainline" features like these in 2.0 then what's
the point of 2.0?

--Ray


----- Original Message -----
From: "Janifer Gatenby" <Janifer.Gatenby@oclc.org>
To: "Ray Denenberg, Library of Congress" <rden@loc.gov>;
<search-ws@lists.oasis-open.org>
Sent: Monday, October 13, 2008 10:07 AM
Subject: RE: [search-ws] proposals page


I've already commented about element set names - I'm against them.

Concerning facets, I think that the browse option should be deleted.
Facets are related to a result set and are used either to narrow the
result set or generate a new search.  Facets are NOT related to browse
which merely positions within an index.

Of the approaches, the inclusion of a new optional element in the search
response is tempting but it involves a change and existing SRU
implementations have already implemented faceted searching using
extraResponseData, e.g. Indiana university see:
http://wiki.dlib.indiana.edu/confluence/display/INF/Faceted+Search

This Indiana example was posted to the SRU list in March and Eric Lease
Morgan sent the following comment:

"The only suggestion I have is in regards to request syntax. Instead of
making the maxValueCount and offset be optional:

   (facetName[,maxValueCount][,offset])...

I suggest they be required:

   (facetName,maxValueCount,offset)...

By making maxValueCount and offset required values, delimited by some
character, it should be easier to parse the request -- it will be
trivial to dump the request into an array and check its validity and
sanity. Finally, just because the values are required does not mean they
can't equal null. This will accommodate for all values or server choice,
as your documentation alludes to."

Thus I think that we should go for the extraResponseData as a suggested
solution.  It fits nicely here because it is a repeated structure.

Janifer


-----Original Message-----
From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
Sent: 10 October 2008 21:06
To: search-ws@lists.oasis-open.org
Subject: [search-ws] proposals page

I have a "proposals" page up at:
http://www.loc.gov/standards/sru/version2proposals.html

No links to it yet and it is unannounced, but I want to announce it by
the end of the day Tuesday, October 14.

Any comments, I need them by 2pm (1400 US Eastern time) Tuesday.

--Ray


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php