[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
Hi all, It has been quiet on this topic for a while.... Do we now have consensus on this topic? That is: - There will be no client-defined date ranges in SRU 2.0. - Things like publicationDate="Last week" or publicationDate="Last hour" will be interpreted by the *server* to reflect the correct range. - There is no need for an additional XML definition for this, as this model fits nicely in the current XML request and response definition for facets. Regards, Edo >>-----Oorspronkelijk bericht----- >>Van: Edward C. Zimmermann [mailto:edz@bsn.com] >>Verzonden: zondag 12 september 2010 19:12 >>Aan: Edo Plantinga; Ray Denenberg, Library of Congress; >>search-ws-comment@lists.oasis-open.org >>CC: 'LeVan,Ralph'; 'OASIS SWS TC' >>Onderwerp: RE: [search-ws-comment] RE: Proposal to remove >>facet range feature from SRU 2.0 >> >>There are a number of ways to crack the same nut. >> >>I see lastWeek in the >> bib.date.published=lastWeek >>as nothing more than just another date or date-range but >>relative not to some fixed mutual time (the civil calender) >>but to some other volatile time--- in my case the date and >>time at which the query is submitted. In ISO 8601 we have >>YYYY-Www[-D] formats and lastWeek is just as I see it a local >>extension to define YYY-Wxx where xx= Current week - 1. In my >>implementation I just extended my date parser with a number >>of local terms which I interpret as I have seen fitting. >> >>There is in my system no "fulltext" term "LastWeek" or "Week" >>or--- OK there can be as the date parser is used to >>determined the dates for the index during index time and a >>date field containing such as term would define a specific >>date w.r.t. the index time (for good or for bad)---- and >>searching for the fulltext term would (probably) find >>nothing. Searching however for the date, resp. range, would >>just as searching for Oct in a field where the date was >>encoded 2002-10-10 should fail but as a date should succeed, >>conversely 2002-10-10 finds 10 Oct 2002. A scan of date field >>in my implementation produces the dates as ISO 8601 dates---- >>its actually a bit more schizophrenic as my object fields >>(dates and date ranges for example) are also searchable and >>scanable as text. >> >>I've found this quite convenient as it lets me search, for >>example, for "today" rather than asking someone to tell me >>what today is from the perspective of the index--- something >>that the searcher might not even know (only "today" in the >>context of some today normalized to a UTC date/time range). >> >>This method could also be used to allow for some interesting >>kinds of queries including as might be desired named dates >>(or ranges) that are not in constant position within the >>civil calendar--- for example Easter (defined as the first >>Sunday following a full moon occurring on or following the >>spring equinox), Rosh Hashanah, Chinese Moon day, Ramadan etc. >> >>The facet part is really distinct from the index as used for >>search. Does the result set contain records that were first >>published last week? Within the past hour? etc.. What makes >>technical sense as a solution to these needs (and speed, >>efficiency etc.) are really application (and also data) specific, viz. >>implementation details and not really method.. >> >> >>On Fri, 10 Sep 2010 09:48:07 -0400, Ray Denenberg, Library of >>Congress wrote >>> 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/ >>> >>> -- >>> 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/ >> >> >>-- >> >>Edward C. Zimmermann, NONMONOTONIC LAB >>http://www.nonmonotonic.net >>Umsatz-St-ID: DE130492967 >> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]