|
I fully agree with
Edwards view on this. I believe there is no need for an extra technical field,
as this IMO would complicate things unnecessarily as this would introduce a
difference between range facets and regular facets (therefore needing a
different stylesheet for dumb clients: not very convenient).
Both Edward and my
own organization have working implementations without the need for an extra
field. However, if somebody can show me a script where an extra field is
really necessary, I am more than happy to be convinced about the need for an
extra field.
On Tue, 19 Oct 2010 14:41:23 -0400, LeVan,Ralph
wrote
> <displayTerm> and
<actualValue> are clearly not redundant. The value to be returned to the
server need not be the same as the value displayed to the user. In HTML forms,
I often see the name of a state in a pull down list (e.g. Ohio), but closer
inspection of the form discloses that the actual value returned is “OH”.
>
As one of the idiots
that developed that model--- I needed it back then--- it was driven by forms
not allowing for "anything" goes. We put the "smarts" into the HTML form
rather than in the process that read them. Someone may, for example, want to
fly to Munich and they don't need to know its IATA code MUC or what LAD
(Dulles) versus LAX (Los Angeles International) is.. Or in city codes that HH
is Hamburg, M is Munich and FFB is Fuerstenfeldbruck. These codes are
for "specialists". There are loads of codes and some are quite obscure. In
interacting with databases we had computerized forms that needed these codes.
The solution was to add a display level. Back in the early 1990s it seemed to
be the easiest pragmatic approach. In static forms it still, I think, makes
sense but not all..
In Scan and Facet, I'd suggest that this need is
not really there. I don't mind having them but they are not absolutely needed.
If my server is smart enough to say that the field content "HH"--- what's
actually in the field--- means "Hamburg" (in Display) it should also be smart
enough to return Hamburg instead of HH and search for HH when someone says
"Hamburg". Again I don't mind having DisplayTerm. But its really not
indespensible.
> There is certainly overlap between <actualValue>,
<query> and <requestUrl>, but that overlap is currently in place.
It is there to support a range of clients, from thin to very smart. I’m not
adding anything new there.
>
> Ralph
>
>
> From: Edo Plantinga
[mailto:Edo.Plantinga@ictu.nl]
> Sent: Tuesday, October 19, 2010
12:27 PM
> To: LeVan,Ralph; Edward C. Zimmermann
>
Cc: Robert van de Rijt; Ray Denenberg, Library of Congress
>
Subject: RE: [search-ws-comment] RE: Proposal to remove facet range
feature from SRU 2.0
>
> Hi
Ralph,
>
> I am not sure why
there is a need for an extra technical field with the content "20101001
20101007" as the same content is also present in <query> and in
<requestUrl>. This seems a little redundant and in our solution we have
no need for an extra field. We have something like <actualTerm> Last
week </actualTerm> and we display that to our users.
>
> Ralph and me had this discussion before, so Edward, I am
curious to hear what you think!
>
> Regards,
> Edo Plantinga - Technisch adviseur CVDR
> __________
> ICTU - Programma e-Overheid voor
Burgers
(fusie van voormalige programma's MijnOverheid en Overheid
heeft Antwoord©
).
> __________
> Voor
technische en andere vragen over de CVDR graag eerst contact met de
servicedesk
> Contactgegevens servicedesk: cvdr@overheid.nl / 070
- 889 61 37
> Contactgegevens persoonlijk:
edo.plantinga@ictu.nl / 070 -
889 6276 / 06 - 2498 1976
>
>
>
>
> Van:
LeVan,Ralph [mailto:levan@oclc.org]
> Verzonden: dinsdag 19
oktober 2010 16:58
> Aan: Edo Plantinga; Edward C. Zimmermann
> CC: Robert van de Rijt; Ray Denenberg, Library of Congress
> Onderwerp: RE: [search-ws-comment] RE: Proposal to remove
facet range feature from SRU 2.0
>
I’m sorry I’ve been silent in these
discussions. I was in Winnipeg last week for Access 2010 and the week
before that I was trying to get some code into production and prepare for my
trip.
>
> I’m quite happy with the document
as it stands. I made a minor addition in the justification
section.
>
> I’d like to make an additional
proposal. I’ve made it before.
>
> I think we need a <displayTerm> subelement
within <term>. This is consistent with how terms are handled in
a Scan response. The addition of this element would allow the server
to send a complex query in the response and still have something simple
displayed to the user. For instance, using our current example (note
the change in the relation value as well as the new
<actualTerm>s):
>
> <facet>
> <facetDisplayLabel> Publication date
</facetDisplayLabel>
> <facetDescription> The date the book was
first published </facetDescription>
> <index> dc.published </index>
> <relation>within</relation>
> <terms>
> <term>
> <displayTerm>Last week</ displayTerm
>
> <actualTerm>20101001
20101007</actualTerm>
> <query>nuthaches AND dc.published within
“20101001 20101007”</query>
> <requestUrl>http://z3950.loc.gov:7090/voyager?query=nuthaches%20AND%20dc.published%20within%20
%2220101001%2020101007%22</requestUrl>
> <count>12 </count>
> </term>
> <term>
> < displayTerm >Last month</
displayTerm >
> <actualTerm>20100901
20100931</actualTerm>
> <query>nuthaches AND dc.published within
“20100901 20100931”</query>
> <requestUrl>http://z3950.loc.gov:7090/voyager?query=nuthaches%20AND%20dc.published%20within%20
%2220100901%2020100931%22</requestUrl>
> <count>8 </count>
> </term>
> </terms>
>
> This allows for the exact same functionality as
before with a great deal more information potentially passed to the
client. It requires the same smarts on the server end; something had
to turn the concept “last week” into a complex query. But, I’ve seen
different architectures where those smarts are in different places and
sometimes it is easier to do the that while producing the response rather
than when processing the subsequent request.
>
> I am not proposing this as a replacement for the
current proposal, but as an addition.
>
> If you’re not opposed to this, I’ll add it to our
prose.
>
> Ralph
>
>
> From: Edo Plantinga
[mailto:Edo.Plantinga@ictu.nl]
> Sent: Tuesday, October 19,
2010 6:13 AM
> To: Edward C. Zimmermann; LeVan,Ralph
>
Cc: Robert van de Rijt; Ray Denenberg, Library of Congress
>
Subject: RE: [search-ws-comment] RE: Proposal to remove facet range
feature from SRU 2.0
>
> Edward,
>
> I agree.
>
> Do you agree that the "anything goes" idea should be
mentioned under the range facets? I think we all agree that the "anything
goes" idea is a server-side mechanism exactly the same as the
mechanism as we suggested for range facets.
> Do you suggest
there should be an extra (short) subchapter? If so, please add it to the
document in whatever way you see fit. Please let's try to wrap the
document up.
>
> Met
vriendelijke groet,
> Edo Plantinga - Technisch adviseur CVDR
> __________
> ICTU - Programma e-Overheid voor
Burgers
(fusie van voormalige
programma's MijnOverheid en Overheid
heeft Antwoord©
).
> __________
> Voor
technische en andere vragen over de CVDR graag eerst contact met de
servicedesk
> Contactgegevens servicedesk:
cvdr@overheid.nl / 070 - 889 61
37
> Contactgegevens persoonlijk:
edo.plantinga@ictu.nl / 070
- 889 6276 / 06 - 2498 1976
>
>
>
>
> Van:
Edward C. Zimmermann [mailto:edz@nonmonotonic.net]
>
Verzonden: dinsdag 19 oktober 2010 11:43
> Aan: Edo
Plantinga; LeVan,Ralph
> CC: Robert van de Rijt; Ray
Denenberg, Library of Congress
> Onderwerp: RE:
[search-ws-comment] RE: Proposal to remove facet range feature from SRU
2.0
> On Tue, 19 Oct 2010 11:08:25 +0200, Edo Plantinga
wrote
> > Hi Edward
(and welcome to the discussion Ray),
> >
> > Thank you for
your elaborate response. I see what you mean. To include this whole
discussion in the specs is a little too much I suppose. Can you please
adjust what you feel is necessary in the specification text? I guess it
boils down to the fact that not only range facets can be defined
server-side, but also more sophisticated conceptual facets (such as "Most
viewed last week": a combination of a # views range and a date range).
Come to think of it: maybe adding "Most viewed last week" can suffice
to illustrate your reasoning?
>
> Really anything goes: "Most viewed last week by pixies".
It does not even have to have (it should but its not mandatory) a public
semantic: "Foo Bar"
>
> Again.. Its not even numerical
ranges but inclusion in some set. The range of numbers 2 to 100 is the set
of all numbers including 2 to 100. That's your numerical range. A date
range is a set of dates (and times). But we have more. We have sets like
"Today's NY Times best selling books list", "Investment buy alert", "On
Sale".. While some of these might be handled by a server as some
numerical range search against some data it does not have to be so
implemented. Publishers seem to have a lot of problems that fall into this
"member of an external set" model. Often these sets themselves are result
sets from a search against some other target--- in db terms its a join.
>
>
> >
> > Let's try to
work towards specifications that are as simple as possible and let's keep
the end goal in sight: the specifications as we are writng them at https://docs.google.com/document/d/1isisseBqaTs_tZfVMf2SryncZLexJInHBmN6u5wgONg/edit?authkey=CLrqy_IB&pli=1#.
> >
> >
> >
Regards,
> > Edo Plantinga - Technisch adviseur CVDR
> > __________
> > ICTU - Programma e-Overheid voor
Burgers
(fusie van voormalige
programma's MijnOverheid en Overheid
heeft Antwoord©
).
> > __________
> > Voor technische en andere vragen over de CVDR graag
eerst contact met de servicedesk
> >
Contactgegevens servicedesk:
cvdr@overheid.nl / 070 - 889 61 37
> > Contactgegevens persoonlijk:
edo.plantinga@ictu.nl / 070 - 889
6276 / 06 - 2498 1976
> >
> >
>
> >
>
> Van: Edward C.
Zimmermann [mailto:edz@nonmonotonic.net]
> > Verzonden:
dinsdag 19 oktober 2010 9:25
> > Aan: Edo Plantinga;
LeVan,Ralph
> > CC: Robert van de Rijt
> >
Onderwerp: RE: [search-ws-comment] RE: Proposal to remove facet
range feature from SRU 2.0
> >
> >
> > On Fri, 15 Oct 2010
11:16:55 +0200, Edo Plantinga wrote
> > > Hi Edward,
> > >
> > > I think "popular" and "most viewed" are not really
range facets (to keep the terminology clear), but they could of course use
exactly the same server-side mechanism. I have included that remark in the
document.
> >
> >
I agree that they are not generally considered when applied as an
attribute within a set since we can always ask for "popular", "most
viewed" ***of the set*** but as aspects of elements within the result set
they are still facets. Applying the terms to the whole of the collection
they are, nearly always, considered facets.
> > But (just to be
a !@#) how about "not yet viewed". A set might now contain any elements
"not yet viewed". What defines "viewed" and "not viewed" is not part of
the collection of records but some other set or collection: the set of
what has been viewed.
> > Another example is "best seller". If
"best seller" is a static set (defined by some business logic) a result
set may contain some "best sellers" or it may contain none. These are not
typically range searches but "element of some other (external)
set".. These "external sets" might be the set of "popular", "most
viewed", "best seller", etc. objects.
> > We are speaking here
thus about an abstraction of our range concept to member of a set.
> >
> > > "Lowest priced" however, *is* a range facet (the
range may be 0-20 USD for example). It is actually a more realistic
example than book size (who cares?) so I replaced it in the Google
document.
> > >
>
>
> > Lowest priced is the "lowest" priced. Its not a range.
"Low priced" is a range (whatever low might mean). Low priced can be an
interesting range since it might now be even absolute 0-20 USD for an item
but based upon a relative model. In common speech the predicate "low
priced" applied to an object among those selling for between 5000 and
beyond 1 million dollars (motorcars) would surely have a different price
than as applied to things whose prices range from 5 to 10 USD. While these
kinds of attributes, albeit range-like, tend to be assigned (by most) in
the metadata itself, e.g. pre-index and not search time there are perhaps
some interesting applications where its not. A search for carbon fibre and
in a result set with motorcars and bicycles, the "low priced" would
contain only bicycles, even those whose attributes are not "low priced"
among the bicycles.
> >
> > Actually "lowest priced"
can be volatile if we consider currencies (and I have, being the nutcase I
am, hooks in my engine to at search time caculate currency exchange rates
and use them in caculated numerical search)--- its just still not a range.
> >
> > > Other than
that, how do you both feel about the text? Are we getting
there?
> >
> >
The whole point we need to convey is that it does not matter what we are
asking in a facet only that the server which claimed that there was such
and such a facet understands it and does what IT thinks is right--- which
might not be what the searcher thinks is right. The intent of the server
implementer might be to try to meet the wishes and demands of the users
but its not more than at least a vague unreachable goal without any
obligations.
> > Just an example: When we say "Last week" the
server knows what it means by "Last week" but the user might think its
something else. To one person it might be the previous Sunday to Sat. and
yet to someone else it might be the previous Monday to Sun or yet another
it might be the past 7 days... Even a simple term like "Today" is not
unambiguous over distance. Nothing even says that the server needs to
interpret the same vocabulary in the same manner for all users---- we can
talk about semantic personalities.
> >
> > >
> > > https://docs.google.com/document/d/1isisseBqaTs_tZfVMf2SryncZLexJInHBmN6u5wgONg/edit?authkey=CLrqy_IB&pli=1#
> > > Met vriendelijke groet,
Edo Plantinga - Technisch adviseur
CVDR __________ Communicatie
omtrent
CVDR: Telefoon Servicedesk (070) 889 61
37 E-mail
algemeen: regelgeving@overheid.nl
__________ ICTU - Programma E-overheid
voor Burgers Telefoon: 070 - 889 6276 / Mobiel:
06-2498 1976 / Email: edo.plantinga@ictu.nl
>
> > >
> > >
>
> Van: Edward C.
Zimmermann [mailto:edz@nonmonotonic.net]
> > >
Verzonden: do 14-10-2010 18:44
> > > Aan: Edo
Plantinga; LeVan,Ralph
> > > CC: Robert van de Rijt
> > > Onderwerp: RE: [search-ws-comment] RE: Proposal
to remove facet range feature from SRU 2.0
> > >
> > >
> > > One of the
things that I think could be useful--- albeit potentially
> >
> distracting--- would be to provide some example vocabulary as
guidance to
> > > people developing their systems.
>
> >
> > > Dates:
> > > Under http://www.ibu.de/DateFormats are my
date, resp. date range, formats---
> > > however obsessive
they seem there are actually quite a few more I coded into
> >
> my parser but they are at this time not officially documented as I
might toss
> > > them out without telling anyone :-)
>
> >
> > > The example of "Large books (over 30cm)" is
similar but I think something
> > > else. Its really a search
for object as book and size>30cm. Should this not
> > >
have been the intent then the example:
> > > "Large (over
30cm)"
> > > is perhaps better but I still think something
else (could just as well just
> > > search for size>30 if
size contains the size in cm as a numerical value or the
> >
> controlled keyword "large" in some assigned field)..
> >
>
> > > There are, of course, a number of other volatile
searches that we've seen poke
> > > their heads.. "most
popular", "most read", "most viewed", "lowest price"
> > >
(including currency flux) that can at the snap of one's fingers change..
> > > these, in contrast, to "last 14 days" can always be
send back in a facet---
> > > last 14 days only if there is
something within the last 14 days--- but that's
> > > getting
into facet-philosophy..
> > >
> > > Of all of
these.. its really these "volatile" date expressions that I think
>
> > have a critical business case.
> > >
> >
> On Sat, 9 Oct 2010 15:11:22 +0200, Edo Plantinga wrote
> >
> > Ok all, I have put the first SRU facet draft on
> >
> https://docs.google.com/document/d/1isisseBqaTs_tZfVMf2SryncZLexJInHBmN6u5wgONg/edit?authkey=CLrqy_IB#.
> > >
> > > >
> > > > I found
range facets were easiest to explain using an example. I'm curious
> > > to see your suggestions. Feel free to edit my draft as
you see fit.
> > > >
> > > > Met
vriendelijke groet,
> > > >
> > > > Edo
Plantinga - Technisch adviseur CVDR
> > > > __________
> > > > Communicatie omtrent CVDR:
> > > >
Telefoon Servicedesk (070) 889 61 37
> > > > E-mail
algemeen: regelgeving@overheid.nl
> > > > __________
> > > > ICTU - Programma E-overheid voor Burgers Telefoon:
070 - 889 6276 / Mobiel:
> > > 06-2498 1976 / Email:
edo.plantinga@ictu.nl
> > > >
> > > >
> > >
-----------------------------------------------------------------------
> > > Van: Edo Plantinga
> > > > Verzonden:
wo 6-10-2010 17:30
> > > > Aan: LeVan,Ralph;
edz@nonmonotonic.net
> > > > CC: Robert van de Rijt
> > > > Onderwerp: RE: [search-ws-comment] RE: Proposal to
remove facet range
> > > feature from SRU 2.0
> >
> >
> > > >
> > > > Allright then,
let's cooperate on this Google document (available for all to
>
> > edit who have this link):
> > > >
> >
> https://docs.google.com/document/edit?id=1isisseBqaTs_tZfVMf2SryncZLexJInHBmN6u5wgONg&hl=nl&authkey=CLrqy_IB
> > >
> > > >
> > > > I am
not sure I'll find the time this week, but I think we've discussed a
> > > fair bit already so it should not take all that much
time.
> > > >
> > > > Shall we invite
anyone who's inclined to join via the mailing list? (note:
> >
> please do not post the link above, as there is no password required
and we
> > > don't want spam).
> > > >
> > > > Met vriendelijke groet,
> > > >
Edo Plantinga - Technisch adviseur CVDR
> > > > __________
> > > > ICTU - Programma e-Overheid voor Burgers (fusie
van voormalige programma's
> > > MijnOverheid en Overheid
heeft Antwoord© ).
> > > > __________
> > >
> Voor technische en andere vragen over de CVDR graag eerst contact met
de
> > > servicedesk
> > > > Contactgegevens
servicedesk: cvdr@overheid.nl / 070 - 889 61 37
> > > >
Contactgegevens persoonlijk: edo.plantinga@ictu.nl / 070 -
> >
> 889 6276 / 06 - 2498 1976
> > > >
> > >
> >>-----Oorspronkelijk bericht-----
> > > >
>>Van: LeVan,Ralph [mailto:levan@oclc.org]
> >
> > >>Verzonden: woensdag 6 oktober 2010 14:51
> >
> > >>Aan: Edo Plantinga; edz@nonmonotonic.net
> >
> > >>CC: Robert van de Rijt
> > > >
>>Onderwerp: RE: [search-ws-comment] RE: Proposal to remove
>
> > > >>facet range feature from SRU 2.0
> > >
> >>
> > > > >>Fine by me!
> >
> > >>
> > > > >>Ralph
> >
> > >>
> > > > >>> -----Original
Message-----
> > > > >>> From: Edo Plantinga [mailto:Edo.Plantinga@ictu.nl]
>
> > > >>> Sent: Wednesday, October 06, 2010 7:36 AM
> > > > >>> To: LeVan,Ralph; edz@nonmonotonic.net
> > > > >>> Cc: Robert van de Rijt
> >
> > >>> Subject: RE: [search-ws-comment] RE: Proposal to
remove facet range
> > > > >>feature
> >
> > >>> from SRU 2.0
> > > > >>>
> > > > >>> Hi Ralph (and Edward, welcome to this
conversation),
> > > > >>>
> > >
> >>> Ah I see. But the 'ugly' search term is hidden in the
> > > > >><query> element
> > >
> >>> and the 'pretty' term can be in <actualTerm>. The
server
> > > > >>only needs to
> > >
> >>> 'know' which 'pretty' term goes with which 'ugly' search
term, but
> > > > >>since
> > > >
>>> everything is server-defined anyway, this is not a problem
IMO.
> > > > >>>
> > > >
>>> Maybe it's a good idea if the three of us (and whoever
> > > > >>wants to join)
> > > >
>>> simply rewrite the SRU 2.0 facet chapter, so we can get
> > > > >>consensus that
> > > >
>>> way. We'll need that definition for our project anyway (since
there
> > > > >>have
> > > >
>>> been a lot of discussions on this topic at this side of the
ocean
> > > > >>> too...).
> > >
> >>>
> > > > >>> I believe that over
the weeks we've pretty much said what there's to
> > > >
>>be
> > > > >>> said, so let's start
wrapping it up. Good idea?
> > > > >>>
>
> > > >>> Met vriendelijke groet,
> > >
> >>> Edo Plantinga - Technisch adviseur CVDR
> >
> > >>> __________
> > > > >>>
ICTU - Programma e-Overheid voor Burgers (fusie van voormalige
>
> > > >>> programma's MijnOverheid en Overheid heeft
Antwoord(c) ).
> > > > >>> __________
>
> > > >>> Voor technische en andere vragen over de CVDR
graag eerst
> > > > >>contact met
> > >
> >>de
> > > > >>> servicedesk
>
> > > >>> Contactgegevens servicedesk: cvdr@overheid.nl
/ 070 -
> > > > >>889
> > > >
>>> 61 37
> > > > >>> Contactgegevens
persoonlijk: edo.plantinga@ictu.nl /
> > > > >>070
> > > > >>> - 889 6276 / 06 - 2498 1976
>
> > > >>>
> > > > >>>
>
> > > >>> >>-----Oorspronkelijk bericht-----
> > > > >>> >>Van: LeVan,Ralph [mailto:levan@oclc.org]
> >
> > >>> >>Verzonden: woensdag 6 oktober 2010 12:40
> > > > >>> >>Aan: Edo Plantinga
>
> > > >>> >>Onderwerp: RE: [search-ws-comment] RE:
Proposal to remove facet
> > > > >>>
>>range feature from SRU 2.0
> > > > >>>
>>
> > > > >>> >>For the same reason
that we have a display term in scan
> > > >
>>responses;
> > > > >>> >>sometimes
the search term is ugly and you can provide something
> > >
> >>> >>prettier to the user.
> > > >
>>> >>
> > > > >>> >>Ralph
> > > > >>> >>
> > > >
>>> >>Edo Plantinga <Edo.Plantinga@ictu.nl> wrote:
> > > > >>> >>
> > > >
>>> >>Hi Ralph,
> > > > >>>
>>
> > > > >>> >>Thanks for the quick
reply.
> > > > >>> >>Why do you feel we
need an extra display field for the term?
> > > >
>>> >>Can we not just use the <actualTerm> for that?
That way
> > > > >>the client
> > >
> >>> >>does not need to 'understand' anything about
range facets. So
> > > > >>> >>something
like:
> > > > >>> >>
> > >
> >>> >><term>
> > > >
>>> >> <actualTerm>Last week</actualTerm>
> > > > >>> >> <query>nuhatches AND
dc.published=lastWeek</query>
> > > > >>>
>> <count>2</count>
> > > > >>>
>></term>
> > > > >>> >>
> > > > >>> >>That is how we decided to
implement it.
> > > > >>> >>
> >
> > >>> >>Met vriendelijke groet,
> > >
> >>> >>Edo Plantinga - Technisch adviseur CVDR
>
> > > >>> >>__________
> > > >
>>> >>ICTU - Programma e-Overheid voor Burgers (fusie van
voormalige
> > > > >>> >>programma's
MijnOverheid en Overheid heeft Antwoord(c) ).
> > > >
>>> >>__________
> > > > >>>
>>Voor technische en andere vragen over de CVDR graag eerst contact
> > > > >>> >>met de servicedesk
>
> > > >>> >>Contactgegevens servicedesk:
cvdr@overheid.nl
> > > > >>> >>/ 070 - 889
> > > > >>> >>61 37
> > > >
>>> >>Contactgegevens persoonlijk:
> > > >
>>> >>edo.plantinga@ictu.nl / 070
> > > >
>>> >>- 889 6276 / 06 - 2498 1976
> > > >
>>> >>
> > > > >>> >>
> > > > >>> >>>>-----Oorspronkelijk
bericht-----
> > > > >>> >>>>Van:
LeVan,Ralph [mailto:levan@oclc.org]
> >
> > >>> >>>>Verzonden: dinsdag 5 oktober 2010
15:00
> > > > >>> >>>>Aan: Edo
Plantinga
> > > > >>> >>>>Onderwerp:
RE: [search-ws-comment] RE: Proposal to remove
> > > >
>>> >>facet range
> > > > >>>
>>>>feature from SRU 2.0
> > > > >>>
>>>>
> > > > >>> >>>>I
still think we need to extend the XML with a display
> > >
> >>form of the
> > > > >>>
>>>>term.
> > > > >>>
>>>>
> > > > >>>
>>>>Ralph
> > > > >>>
>>>>
> > > > >>> >>>>Edo
Plantinga <Edo.Plantinga@ictu.nl> wrote:
> > > >
>>> >>>>
> > > > >>>
>>>>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
> > > > >>> >>>>>>
> > > > >>> >>>>>>
>
> > > >>> >>>>
> > > >
>>> >>>>
> > > > >>>
>>>>
> > > > >>> >>
>
> > > >>> >>
> > > > >>>
>>
> > > > >>
> > > > >>
> > > > >>
> > >
> > > --
> > >
> > > 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
> > > Telephone: Voice:= +49 (89) 385-47074
Corp.Fax:= +49 (89) 692-8150
> > > Nomadic (SMS/MMS/Fax):=
+49 (176) 100-360-55 Alt.Mobile:= +49 (179) 205-0539
> > > http://www.nonmonotonic.net
>
> > Umsatz-St-ID: DE130492967
> > >
> > >
> >
> > --
> >
> > 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
> > Telephone: Voice:= +49 (89) 385-47074 Corp.Fax:=
+49 (89) 692-8150
> > Nomadic (SMS/MMS/Fax):= +49 (176)
100-360-55 Alt.Mobile:= +49 (179) 205-0539
> > http://www.nonmonotonic.net
>
> Umsatz-St-ID: DE130492967
> >
>
>
> --
>
> 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
> Telephone: Voice:= +49 (89)
385-47074 Corp.Fax:= +49 (89) 692-8150
> Nomadic
(SMS/MMS/Fax):= +49 (176) 100-360-55 Alt.Mobile:= +49 (179) 205-0539
> http://www.nonmonotonic.net
>
Umsatz-St-ID: DE130492967
--
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
Telephone:
Voice:= +49 (89) 385-47074 Corp.Fax:= +49 (89) 692-8150
Nomadic (SMS/MMS/Fax):= +49 (176) 100-360-55 Alt.Mobile:= +49 (179)
205-0539
http://www.nonmonotonic.net
Umsatz-St-ID: DE130492967
|