RE: [search-ws-comment]Forms versus Scan and Facet // was: ....

["LeVan,Ralph" <levan@oclc.org>]

I think we are in agreement that rangeFacets look just like regular
facets now.  The only issue we are debating is whether there should be a
form of the facet term sent to the client for display only and not to be
returned ever to the server.  If we agree that <query> and <requestURL>
are redundant and can be ignored for the purposes of our discussion,
then is the single subelement <actualTerm> of <term> sufficient for all
purposes?

As for an example:
<facet>
  <facetDisplayLabel> Co-Authors </facetDisplayLabel> 
  <facetDescription> Other authors this author worked with
</facetDescription>
  <index> bib.lccn </index>
  <relation>=</relation>
  <terms>
    <term>
      <actualTerm>n201012345</actualTerm>
      <displayTerm>Ralph LeVan</actualTerm>
      <count>12 </count>
      </term>
    </terms>
  </facet>

In this example, there is no index that supports looking up names.
There is only an LCCN index.  LCCN is worthless for display to the user.

Ralph

> -----Original Message-----
> From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl]
> Sent: Wednesday, October 20, 2010 11:30 AM
> To: LeVan,Ralph; Edward C. Zimmermann
> Cc: Ray Denenberg, Library of Congress; search-ws-comment@lists.oasis-
> open.org
> Subject: RE: [search-ws-comment]Forms versus Scan and Facet // was:
....
> 
> 
> Ralph,
> 
> I suspected something like this was our confusion. We use <actuaTerm>
in
> our solution to display to our users, just like in regular facets (and
> yes, <displayTerm> would be a better term for it, I agree with that).
> What I am saying is we *do* need something like "last week" (whether
you
> want to name it <actualTerm> or <displayterm>, as long as it's the
> *same* for regular facets and range facets). I am also saying that we
do
> *not* need something like "lastWeek", as this is also present in
<query>
> and <requestUrl>. I think "smart" clients would either use
> <query>/<requestURL>, or they would be smart enough to remember the
> "lastWeek" value. But I am still willing to be convinced otherwise
with
> a script example.
> 
> Edo
> 
> >>-----Oorspronkelijk bericht-----
> >>Van: LeVan,Ralph [mailto:levan@oclc.org]
> >>Verzonden: woensdag 20 oktober 2010 17:05
> >>Aan: Edo Plantinga; Edward C. Zimmermann
> >>CC: Ray Denenberg, Library of Congress;
> >>search-ws-comment@lists.oasis-open.org
> >>Onderwerp: RE: [search-ws-comment]Forms versus Scan and Facet
> >>// was: ....
> >>
> >>Ah, I'm starting to see your confusion!
> >>
> >><actualTerm> is the value that must be returned to the
> >>server.  Until now, it was also the form of the term to be
> >>displayed to the user.  I'm proposing that an explicitly
> >>displayable form of the term be returned.
> >>
> >><actualTerm>, <query> and <requestURL> are overlapping
> >>concepts.  The value of actualTerm MUST be in the query
> >>somewhere and the URL encoded query MUST be in the
> >>requestURL.  The <query> and <requestURL> elements are
> >>provided for thin/stupid clients that can't figure out how to
> >>form a query from the original query plus the actualTerm.
> >>
> >>So, if you ignore <query> and <requestURL> as being
> >>redundant, then the <term> element only has one subelement:
> >><actualTerm>.  I am proposing that we add <displayTerm>.
> >>
> >>In no way are actualTerm, query or requestURL alternatives to
> >>the displayTerm that I am proposing.
> >>
> >>Ralph
> >>
> >>> -----Original Message-----
> >>> From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl]
> >>> Sent: Wednesday, October 20, 2010 9:55 AM
> >>> To: LeVan,Ralph; Edward C. Zimmermann
> >>> Cc: Ray Denenberg, Library of Congress
> >>> Subject: RE: [search-ws-comment]Forms versus Scan and Facet //
was:
> >>....
> >>>
> >>> Ralph,
> >>> I believe we already *have* two such value fields, namely
> >><query> and
> >>> <requestUrl>. Since the discussion seems to be getting
> >>stuck on this,
> >>I
> >>> suggest you give an example of a script (in plain English or
pseudo
> >>> code) that needs the extra value field you suggest, but cannot
work
> >>with
> >>> <query> and <requestURL> alone.
> >>>
> >>> So what I am suggesting is that we only need these three,
> >>and no more:
> >>> <actualTerm>Last week</actualTerm>     =====> this one's for
display
> >>to
> >>> users
> >>> <query>nuthaches AND dc.published=Last week</query>     =====>
this
> >>> one's for computers that need to do some manipulation
> >>>
> >><requestUrl>http://z3950.loc.gov:7090/voyager?query="nuthaches
> >>%20AND%20
> >>> d
> >>> c.published=Last%20week"   </requestUrl>     =====> this one's for
> >>> computers to use for constructing a hyperlink for a user to
> >>click on
> >>> (combined with <actualTerm>).
> >>>
> >>> If you can show me such a script that needs more info than
> >>above, I am
> >>> happily convinced.
> >>>
> >>> Edo
> >>>
> >>>
> >>> >>-----Oorspronkelijk bericht-----
> >>> >>Van: LeVan,Ralph [mailto:levan@oclc.org]
> >>> >>Verzonden: woensdag 20 oktober 2010 15:13
> >>> >>Aan: Edward C. Zimmermann; Edo Plantinga
> >>> >>CC: Ray Denenberg, Library of Congress; Robert van de Rijt
> >>> >>Onderwerp: RE: [search-ws-comment]Forms versus Scan and Facet //
> >>> >>was: ....
> >>> >>
> >>> >>In XForms, items in select lists have both labels and values.
> >>> >> They clearly see a need to display one thing to the user
> >>and return
> >>> >>something completely different to the server.  I continue
> >>to claim
> >>> >>that this is a parallel functionality.
> >>> >>
> >>> >>Ralph
> >>> >>
> >>> >>> -----Original Message-----
> >>> >>> From: Edward C. Zimmermann [mailto:edz@nonmonotonic.net]
> >>> >>> Sent: Wednesday, October 20, 2010 4:21 AM
> >>> >>> To: Edo Plantinga; LeVan,Ralph
> >>> >>> Cc: Ray Denenberg, Library of Congress; Robert van de Rijt
> >>> >>> Subject: RE: [search-ws-comment]Forms versus Scan and Facet //
> >>was:
> >>> >>....
> >>> >>>
> >>> >>> HTML Forms:
> >>> >>>
> >>> >>> In XForms we have labels and variables:
> >>> >>>
> >>> >>> <input ref="fname"><label>First Name</label></input>
> >>> >>>
> >>> >>> The First Name is what is displayed and in XForms the
> >>elements get
> >>> >>jammed
> >>> >>> into
> >>> >>> a template.. filling the tags: here fname
> >>> >>>
> >>> >>> This can be also a path:
> >>> >>>  <input ref="/my:person/my:fname"> etc..
> >>> >>>
> >>> >>> Because of this in XForms ***every*** input must have a label
> >>> >>(***mandatory
> >>> >>> element***).
> >>> >>>
> >>> >>> Just on the basis of naming we have this problem given the
> >>> >>restrictions on
> >>> >>> element names (can't start with a number, no spaces, etc.)
> >>> >>>
> >>> >>>
> >>> >>> Scan/Facet:
> >>> >>>
> >>> >>> Is the DisplayTerm really analogous in its need to label?
> >>> >>The term is
> >>> >>not a
> >>> >>> structural element to be filled.
> >>> >>>
> >>> >>> Getting back a term from a last name field "Zimmermann".
> >>> >>Zimmermann is
> >>> >>not a
> >>> >>> tag but rather, looking at forms, the content of an
> >>> >>element. There are
> >>> >>no
> >>> >>> restrictions on what the Term sub-elements (Display etc.)
> >>> >>can contain.
> >>> >>>
> >>> >>> I think we can all live quite well without a
> >>DisplayTerm (thinking
> >>> >>Forms:
> >>> >>> label) in Scan. With our "anything goes" approach in Facet as
> >>well..
> >>> >>>
> >>> >>> And my idea for some kind of verbose "Description"--- not like
> >>label
> >>> >>in XForms
> >>> >>>  but more like help and hint--- for a facet element? Here I
see
> >>some
> >>> >>business
> >>> >>> cases in a number of applications including ecommerce/shops
(one
> >>of
> >>> >>the
> >>> >>> applications where Facets is king).
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>>
> >>> >>>  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
> >>> >>>
> >>> >>
> >>> >>
> >>> >>
> >>
> >>
> >>