[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws-comment] "Last Week" is a bad idea for <actualValue>
For the record: I still totally agree with Edward's take on this.
Since we seem to have started to repeat our arguments, I suggest
somebody (Ray?) a) makes a decision or b) proposes a procedure how to
reach consensus (e.g. ask another facet expert whose opinion we will
follow, do a majority vote, provide (pseudo) code examples, whatever). I
personally feel the mailing list discussion is not leading anywhere
anymore. I am willing to take the discussion to a procedural level, but
if the discussion will continue at the content level, I regret to say I
will unsuscribe from the mailing list.
Regards,
Edo
>>-----Oorspronkelijk bericht-----
>>Van: Edward C. Zimmermann [mailto:edz@nonmonotonic.net]
>>Verzonden: dinsdag 26 oktober 2010 10:09
>>Aan: LeVan,Ralph; Ray Denenberg, Library of Congress;
>>search-ws-comment@lists.oasis-open.org
>>Onderwerp: RE: [search-ws-comment] "Last Week" is a bad idea
>>for <actualValue>
>>
>>The combination using the "anything does" approach is, I
>>think, much easier. A field called "Foo" getting searched by
>>a term "LastWeek" looks no different than a field called
>>"Author" getting searched by a term "LeVan". The server needs
>>to know what to do.. and what the server does is what the
>>server thinks is best since its the server that provided in
>>these cases the terms "LastWeek"
>>for the "Foo" field and "LeVan" for the "Author" field in
>>scan and facet. It makes life very easy...
>>
>>Now Raph will say.. and what about a term that's a query:
>>"Cat or Dog". But..
>>Its NOT a query. Its not the expression ("Cat" || "Dog") its
>>"Cat or dog".
>>Since the server provided it its no different than if the
>>server provided "LeVan,Raph", "Alfred E. Neuman" or "To be or
>>not to be". What the server does with "Cat or Dog" is up to
>>the server. It provided it and it will handle it accordingly
>>(from the perspective of the server).
>>
>>Without this approach I think things get very difficult.
>>
>>And we are liberated from any restrictions to keep things to
>>ranges, durations and intervals.
>>
>>Ralph feels that this fails to "teach[es] the developer
>>something about your server's capabilities."
>>I did not know that this was a priority.. or relevant.. even
>>replacing the word "developer" for "smart clients"..
>>I don't think showing a developer (of what??) that terms such
>>as "LastWeek" or "Mondays since 1927" work won't teach him
>>something.. :-)
>>
>>
>>
>>On Mon, 25 Oct 2010 21:05:13 -0400, LeVan,Ralph wrote
>>> In scan, the term is the query. For facets, the facet term
>>has to be
>>> combined with the previous query and that can be tricky.
>>>
>>> Ralph
>>>
>>> "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:
>>>
>>> " It demonstrates that you have a date index that can be used for
>>> range searches .. "
>>>
>>> Now I don't want to open up a whole nother can of worms.
>>But doesn't
>>> this argue for yet one more element . a query. If you
>>return the term
>>> "20101017 20101023" is the client likely to be able to formulate a
>>> valid query without any help? We do it for facets, return a query
>>> with each facet term.
>>>
>>> --Ray
>>>
>>> From: LeVan,Ralph [mailto:levan@oclc.org]
>>> Sent: Monday, October 25, 2010 10:28 AM
>>> To: Edo Plantinga; search-ws-comment@lists.oasis-open.org
>>> Subject: RE: [search-ws-comment] "Last Week" is a bad idea for
>>> <actualValue>
>>>
>>> The has nothing to do with client-defined range facets. The client
>>> has the option to specify what facets get returned and the
>>server gets
>>> to decide what ranges are returned to the client. None of that has
>>> changed.
>>>
>>> The issue is the value that gets returned in the
>>server-defined range.
>>> Ed has advocated for the <actualValue> returned to be a
>>magic string
>>> such as "Last Week". I suggest that a more useful value
>>for developer
>>> educational purposes would be "20101017 20101023" as it
>>would show the
>>> developer how to use ranges in other queries. It demonstrates that
>>> you have a date index that can be used for range searches
>>and you give
>>> an example of such a range search in your facet response.
>>This gets
>>> away from server "magic"
>>> and teaches the developer something about your server's
>>capabilities.
>>>
>>> Ralph
>>>
>>> From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl]
>>> Sent: Monday, October 25, 2010 10:13 AM
>>> To: LeVan,Ralph; search-ws-comment@lists.oasis-open.org
>>> Subject: RE: [search-ws-comment] "Last Week" is a bad idea for
>>> <actualValue>
>>>
>>> We *don't* have client-defined range facets, therefore the
>>developer
>>> cannot figure out how to create such a query anyway. Your argument
>>> does not hold true for server-defined facets. To put it another way:
>>> there will be no sending of strings that have not been sent
>>first by
>>> the *server*, and therefore there will be no "url hacking"
>>or "query
>>> hacking".
>>>
>>> _____
>>>
>>> Van: LeVan,Ralph [mailto:levan@oclc.org]
>>> Verzonden: maandag 25 oktober 2010 16:02
>>> Aan: search-ws-comment@lists.oasis-open.org
>>> Onderwerp: [search-ws-comment] "Last Week" is a bad idea for
>>> <actualValue>
>>>
>>> I've been giving more thought to our facets conversation and have
>>> decided that I don't like "Last Week" as a term to be sent
>>back to the
>>> server. I'm not saying it is illegal or that the standard won't
>>> support it. I'm just saying I think it is a bad idea.
>>>
>>> The reason is that it depends on server magic. The client, or more
>>> importantly the developer, won't learn anything about how
>>to construct
>>> other range queries if we hide how it is done behind magic
>>strings.
>>> If, instead, we send "20101017 20101023" as the
>><actualTerm>, then the
>>> developer might be able to figure out how to create their own query
>>> for "Two Weeks Ago".
>>>
>>> Of course, an <actualTerm> of "20101017 20101023" would want a
>>> <displayTerm> of "Last Week".
>>>
>>> Ralph
>>>
>>> --
>>> 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
>>Basis Systeme netzwerk, Munich Ges. des buergerl. Rechts
>>Office Leo (R&D):
>> Leopoldstrasse 53-55, D-80802 Munich,
>> Federal Republic of Germany
>>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]