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] Facet ranges in SRU 2.0


Title: RE: [search-ws-comment] Facet ranges in SRU 2.0
Thanks for thinking with me and sorry for the late reply: it's been a busy week...
Before I reply, let me start by saying I am using these documents only as the basis of this discussion:
the example response XML at http://www.loc.gov/standards/sru/oasis/schemas/facetedResults.xml and the SRU 2.0 specifications at http://www.loc.gov/standards/sru/oasis/current/sru-2-0.doc. If I missed something, please let me know.
 
I think we are getting somewhere. Ray said:
"What I think you are asking for is
-  an additional request parameter, for example  &rangeFacetLabel="published last week"; and
-  an additional response element,  <rangeFacetLabel>, a subelement of facet, which simply echoes the request element. "
Ralph agrees that there is need for an extra response element, but he suggests that it should be a daughter element of <term> (which in turn is a daughter element of <facet>. I agree with that. 
 
However, I believe that on of the problems we are encountering here is that there is a hierarchical relationship in both the request parameters and the response XML. I believe the response part has been solved by Ralph's suggestion, but I think the issue for the request part remains: there are no hierarchic request parameters and hierarchy in a URL is not ideal. I believe there are two things that could be done here:
1). Avoid the request problem altogether by not allowing the client to specify request parameters for range facets. If a client requests a facet on dcterms:issued, the *server* will decide that:
A) the <facetDisplayLabel> should be, say, "Publication date" (I am assuming the server always chooses the facetDisplayLabel as there is no way to define it in the request parameters, by the way) and
B) that the facet terms are both defined *and* labeled as, say, "First quarter 2010", "Second quarter 2010" and "Third quarter 2010".
My reasoning is this: To me it does not make practical sense to allow a client to define a range but not allow a client to label the range (otherwise the server has to guess a logical name, and how is a computer supposed to know what a logical name for a range is?). Also it does not make sense to me to allow the definition of only one range per index (since that is not really a facet imho).
2) Have some sort of hiërarchical way of requesting facets, so that a cliënt could request the following facet (in natural language):
- Give me a facet on dcterms:issued with facet terms:
   "First Quarter 2010" (defined as 1-1-2010 until 31-3-2010),
   "Second Quarter 2010" (defined as 1-4-2010 until 31-6-2010),
   "Third Quarter 2010" (defined as 1-7-2010 until 31-9-2010),
There is an hierarchical XML suggestion for this at http://facetmap.com/demo/browse.jsp (look under browse price) and http://facetmap.com/spec/, but this will not work for URL defined facets (because of the hierarchical relationship). In SOLR the problem has been solved partly: http://wiki.apache.org/solr/SimpleFacetParameters#Facet_by_Range
Maybe something like this would work:
&facetRangeField=dcterms:issued
&facetTermLabel:dcterms:issued="First Quarter 2010"&facetLowvalue=1-1-2010&facetHighvalue=31-3-2010
&facetTermLabel:dcterms:issued="Second Quarter 2010"&facetLowvalue=1-4-2010&facetHighvalue=31-6-2010
&facetTermLabel:dcterms:issued="Third Quarter 2010"&facetLowvalue=1-7-2010&facetHighvalue=31-9-2010
The underlying assumption would be that each itemlabel and each definition would be mentioned consecutively (preserving the sister-sister relationship). Hmmm, I don't know.... 
Or maybe defining a help variable is the best way:
&facetRangeField=dcterms:issued
&rangeField:dcterms:issued:tempvar=Q1&facetTermlabel.Q1="First Quarter 2010"&facetLowvalue.Q1=1-1-2010&facetHighvalue.Q1=31-3-2010
Hmm, I don't know...
 
To me the 1) alternative is best: you lose some of the flexibility, but for many collections this is not such a problem I guess. On the up side: this alternative is less complicated and keeps the SRU standard manageable.
The 2) alternative is more flexible, but too complicated i.m.o.  
 
I am curious to hear your reply.
 
Kind regards,
 
Edo


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]