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


Title: RE: [search-ws-comment] RE: Proposal to remove facet range feature from SRU 2.0
Hi Ray,
 
Thanks again for your suggestions.The quote you mentioned was not mine by the way, but it was Edward's.
 
I did not have the time to discuss your post below with my collegues here, and I will be on holiday next week. So not to delay things too much, I will give my first quick response:
Having a second index to maintain the "last week", "last month" etc. values does not seem very efficient to me. Although it would be possible, the server would need to update this index on a daily basis. This can be quite costly, let alone if you wanted a term "last 15 minutes" (which may not make a lot of sense in the library domain, but probably in other domains it would). So my suggestion would be that the the server would translate ...publicationDate="Last week"... to something like ....(publicationDate > (today-7) ) AND ( publicationDate <= today ). That way a range facet would behave just like any other facet from the client's perspective.  In other words: "Last week" is just shorthand for the definition of the range, and the server would understand this, make the translation and deliver the results only within that range.
 
-- Edo

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?

--Ray



-----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

Ray,

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.

Regards,

Edo


>>-----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>.
>>
>>--Ray
>>
>>-----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.
>>
>>Regards,
>>
>>Edo
>>
>>
>>

--
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
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws
Join OASIS: http://www.oasis-open.org/join/



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