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: RE: [search-ws-comment] RE: Proposal to remove facet range feature from SRU 2.0

Edo - Again I think we're not completely clear about your index model.

If you have an index/facet 'publicationDate', it could have terms like:
'lastWeek', 'thisWeek',  .... or it could be an index of dates.   But it
can't be both.   

So when you suggested (several messages ago):

"bib.date.published=lastWeek Its up to your server to understand what the
date "lastWeek" (or "Last Week" or "This Week" or .. .) means and do the
right thing...."

... that raised some questions. To start:  Do you have an index,  with a
name like 'publicationDate' (it doesn't matter what it's called) with terms
like 'lastWeek', 'thisWeek'  .... AND for each term, an index by that name
with associated dates.  So for example if there were a term 'lastWeek' in
the index 'publicationDate' then there would be an index 'lastWeek' whose
terms are all dates, from last week.

Is this your model?


-----Original Message-----
From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl] 
Sent: Wednesday, September 08, 2010 6:09 AM
To: Denenberg, Ray; search-ws-comment@lists.oasis-open.org
Cc: OASIS SWS TC; LeVan,Ralph
Subject: [search-ws-comment] RE: Proposal to remove facet range feature from
SRU 2.0


In my opinion there is no need for extra fields in the XML response, as
"Last Week", "Last Month" etc. behave just like normal facet terms from the
client's perspective (i.e. just like "Nuthatches" and "Birds" in the example
of SRU 2.0). I believe how the server decides to implement the standard
(using extra indexes or using CQL-like constraints) is up to the server, and
does not need to be specified in the SRU standard (naturally they do need to
be defined for the programmers that will build the server). 

If the ranges of the defined terms are not obvious, say "Old books", "New
books", the designer of the service can choose more descriptive labels like
"Old books (1900 and before)" and "New books (after 1900)".
This is how you would present it to the user, and in my opinion that is all
we need. I do not think that the facetLowest and facetHighest values need to
be machine-readable, because I can't see any scenario's in which a computer
will actually do something with these values (other than presenting them to
the user). But maybe I am missing something. As benefit of not defining
extra response elements, the standard will be kept as simple as possible. 
I am curious to hear your opinion. 



>>-----Oorspronkelijk bericht-----
>>Van: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
>>Verzonden: dinsdag 7 september 2010 20:35
>>Aan: Edo Plantinga; search-ws-comment@lists.oasis-open.org
>>CC: 'OASIS SWS TC'; 'LeVan,Ralph'
>>Onderwerp: RE: Proposal to remove facet range feature from SRU 2.0
>>Edo - I suggest the following approach for the server-defined facet 
>>range feature.
>>First, assume a model where you for a given range-type facet, like 
>>publication date, you have two indexes: (1) a publicationDate index, 
>>where you index all the publication dates; and (2) a 
>>publicationDateRange index with terms like 'thisWeek', 'lastWeek',
>>'twoWeeksAgo','lastTwoWeeks','lastMonth', etc.   
>>And say that the latter index is the facet.  
>>Of course there needs to be a way to express the relationship of the 
>>latter index to the first.  We can solve that problem in the schema: 
>>add an element with a name like <associatedIndexIfRangeFacet> under 
>><facet>.  In addition we could add in the schema, for each facet term, 
>>its lowest and highest value, under <term>.
>>-----Original Message-----
>>From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl]
>>Sent: Tuesday, September 07, 2010 11:16 AM
>>To: Denenberg, Ray; search-ws-comment@lists.oasis-open.org
>>Cc: OASIS SWS TC; LeVan,Ralph
>>Subject: RE: Proposal to remove facet range feature from SRU 2.0
>>Good to see Ray's proposal, needless to say I agree. 
>>However, in my opinion the 2.0 specs should mention the alternative
>>mechanism: the *server-defined* facet ranges (only
>>*client-defined* facet ranges are dropped according to Ray's 
>>proposal). Ideally there would also be an example of how the 
>>server-client interaction messages are handled (such as in Edward's 
>>recent post to this mailing list).
>>Otherwise people may conclude that facet ranges are not possible in 
>>SRU, which is not the case.

This publicly archived list offers a means to provide input to the OASIS
Search Web Services TC.

In order to verify user consent to the Feedback License terms and to
minimize spam in the list archive, subscription is required before posting.

Subscribe: search-ws-comment-subscribe@lists.oasis-open.org
Unsubscribe: search-ws-comment-unsubscribe@lists.oasis-open.org
List help: search-ws-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/search-ws-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Join OASIS: http://www.oasis-open.org/join/

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