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


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]