[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
I notice that the CQL diagnostics are omitted. How should I refer to them in the Scan document? We ought to have some sort of pointer to them in both SearchRetrieve and Scan documents. Ralph > -----Original Message----- > From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] > Sent: Friday, October 08, 2010 10:38 AM > To: 'Edo Plantinga'; '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 > > 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]