10 messages in org.oasis-open.lists.search-ws-commentRE: [search-ws-comment]Forms versus S...| From | Sent On | Attachments |
|---|---|---|
| LeVan,Ralph | Oct 20, 2010 8:04 am | |
| Edo Plantinga | Oct 20, 2010 8:29 am | |
| LeVan,Ralph | Oct 20, 2010 8:54 am | |
| Edward C. Zimmermann | Oct 21, 2010 5:40 am | |
| Edo Plantinga | Oct 21, 2010 6:39 am | |
| LeVan,Ralph | Oct 21, 2010 8:21 am | |
| LeVan,Ralph | Oct 21, 2010 8:25 am | |
| Edward C. Zimmermann | Oct 21, 2010 9:11 am | |
| LeVan,Ralph | Oct 21, 2010 10:33 am | |
| Edward C. Zimmermann | Oct 21, 2010 12:10 pm |
| Subject: | RE: [search-ws-comment]Forms versus Scan and Facet // was: .... | |
|---|---|---|
| From: | LeVan,Ralph (lev...@oclc.org) | |
| Date: | Oct 20, 2010 8:54:21 am | |
| List: | org.oasis-open.lists.search-ws-comment | |
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....@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:lev...@oclc.org] Verzonden: woensdag 20 oktober 2010 17:05 Aan: Edo Plantinga; Edward C. Zimmermann CC: Ray Denenberg, Library of Congress; sear...@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....@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:lev...@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:ed...@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
-- 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: sear...@lists.oasis-open.org Unsubscribe: sear...@lists.oasis-open.org List help: sear...@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/