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


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws-comment message

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

Subject: 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. 

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