[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
See the lastest SRU 2.0 draft, http://www.oasis-open.org/apps/org/workgroup/search-ws/download.php/39444/sr u-2-0-draft-september-21-2010.doc Note that the range facet parameters have all been removed. I think this reflect consensus among us and that all outstanding issues are resolved. --Ray -----Original Message----- From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl] Sent: Tuesday, October 05, 2010 8:03 AM To: Edward C. Zimmermann; Denenberg, Ray; search-ws-comment@lists.oasis-open.org Cc: LeVan,Ralph; OASIS SWS TC; Robert van de Rijt; [name removed by OASIS admin] 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 >> >> -- 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]