[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [search-ws] Another Kind of Facet?
But, in this case the facet is not an additional component added to the
query, as our current facets model would imply. You see that in the
facet xml itself, where the assumption is that terms from an index added
to the current query define the facet. My facets don't match that
model. I can't provide a value to go in that <index> element, much less
the rest of the values in the <facet> element.
I'm also reconsidering the existing facets. For thin clients, adding
something to the query is not trivial. I think I'd like to add a <link>
element that contains the complete URL necessary to access the facet.
This would be in addition to the <index>, <relation> and <terms>
elements. They are very valuable for smart clients and should be sent
if available.
Ray, at one time you had names for the facets. Those became unnecessary
when we focused facets on indexes. But now that we've opened the
possibility that they might be something more, the need for an optional
<name> element comes back. Probably repeatable with a lang attribute.
So, maybe something like this?
<facets>
<facet>
<name>Personal Names</name>
<link>http://...</link>
<facet>
<facet>
<index>dc.source</index>
<relation>exact</relation>
<term>Library of Congress</term>
<link>http://....</link>
</facet>
</facets>
Ralph
> -----Original Message-----
> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov]
> Sent: Wednesday, March 18, 2009 10:30 AM
> To: search-ws@lists.oasis-open.org
> Subject: Re: [search-ws] Another Kind of Facet?
>
> (Sorry I neglected this issue for so long, I'm trying to catch up.)
>
> I don't think this is out-of -scope, nor too unique a requirement, nor
> do I
> think it would be difficult to accomodate.
>
> Remember, I'm the one who originally suggested returning queries in
> the
> facet results, but everyone thought it was a bad idea. I still like
the
> idea. Or just supply a base URL. Add another (higher) level
> "dataSource".
>
> Something like this:
>
> <facetedResults>
>
> <dataSource>
> <baseURL> http:// ....... </baseURL>
> <facets>
> <facet>
> <index>dc.source</index>
> <relation>=</relation>
> <terms>
> ........
> </terms>
> </facet>
> <facet>
> .....................
> </facet>
> <facets>
> </dataSource>
>
> <datasource>
> ......
> </datasource>
>
> </facetedResults>
>
>
> What do you think?
>
> --Ray
>
> ----- Original Message -----
> From: "LeVan,Ralph" <levan@oclc.org>
> To: "Nick Nicholas" <opoudjis@optushome.com.au>;
> <search-ws@lists.oasis-open.org>
> Sent: Tuesday, March 10, 2009 10:06 AM
> Subject: RE: [search-ws] Another Kind of Facet?
>
>
> Maybe I haven't explained myself well enough.
>
> I have a database named Identities
> (http://worldcat.org/identities/search/Identities). It is actually
> composed of 4 other databases; PersonalIdentities,
CorporateIdentities,
> SubjectIdentities and AbandonedIdentities. When I search the
> Identities
> database, its results are the sum of the results of the searches of
the
> 4 component databases.
>
> I report back the summed result. But, there are components to that
> search that I could expose as well. Up until now, we assumed those
> components would come as the result of refinements on the original
> query. But, I have a case where the components can be viewed by
> pointing the user at another database.
>
> Having done a search for "smith", the user sees that there are facets
> restricting the search to "Personal", "Corporate" or "Subject" names.
> I
> would like to expose a link to a result that restricts the user's
> search
> to that facet of the original query. I would do that by providing an
> SRU URL, complete with query, to the appropriate component database.
>
> Again, I'm prepared to hear that this is completely out of scope or
too
> unique a requirement to worry about. I'm writing the code now to
> return
> this information in extraResponseData and won't be disappointed if no
> official action happened on this.
>
> I just thought I'd ask if anyone else thought this was something that
> our current facet design should be extended to accommodate.
>
> Thanks!
>
> Ralph
>
> > -----Original Message-----
> > From: Nick Nicholas [mailto:opoudjis@gmail.com] On Behalf Of Nick
> > Nicholas
> > Sent: Monday, March 09, 2009 8:10 PM
> > To: search-ws@lists.oasis-open.org
> > Subject: Re: [search-ws] Another Kind of Facet?
> >
> > Kneejerk reaction: the data model of SRU certainly only had a single
> > data source, and differences between component data sources were not
> > scoped. Rather than build in a notion of constituent data sources as
> a
> > primitive in the source spec, and messing it up, I would be far more
> > comfortable with "data source" being just another facet specified by
> > the query server, as a best practice.
> >
> > I don't see how SRU URLs of databases belongs to facet queries: this
> > is metadata about facets, but the query response should be
> > presupposing the existence of facets, not explaining them. That's
the
> > business of an Explain function, really.
> >
> > On 10/03/2009, at 06:42, LeVan,Ralph wrote:
> >
> > > I have failed in my first application of facets. I understand
that
> > > what I'm trying to do is outside of what we designed for, but I'm
> > > looking for opinions as to whether we need to extend the current
> > > facet design to accommodate my problem.
> > >
> > > I have an SRW database that does a federated search across a
number
> > > of other SRW databases and returns a single response. But, I
would
> > > like to return the counts and SRU URLs for the component
databases.
> > > There is no way to pass such information through the current facet
> > > interface.
> > >
> > > Opinions are welcome!
> > >
> > > Thanks!
> > >
> > > Ralph
> >
> > --
> > Dr Nick Nicholas: Link Affiliates opoudjis@optushome.com.au
> > http://www.opoudjis.net skype:opoudjis
> > "Must I, then, be the only one to be beheaded now?" "Why, did you
> > want
> > everybody to be beheaded for your consolation?" Epictetus,
Discourses
> > 1.1.
> >
> >
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail. Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]