[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? --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]