[XESAM] Questions regarding Xesam Query Language

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Mon Sep 17 05:12:31 PDT 2007


2007/9/17, Anders Rune Jensen <anders at iola.dk>:
>
> On 9/17/07, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com> wrote:
> > 2007/9/17, Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> > > 2007/9/17, Anders Rune Jensen <anders at iola.dk>:
> > >
> > > > Hi
> > > >
> > > > I've been reading the Xesam Query Language specification and I have
> a
> > questions:
> > > >
> > > > 1) How do I get all tags for all files? Preferable as list<name,
> > > > count>. The same is true for other attributes such as mime-types.
> > >
> > >
> > > You are right that there is no obvious way to do this atm. I think the
> > best solution is to simply add a new selector called "any", and use it
> like
> > the following.
> > >
> > > Firstly note that the ontology does not yet implement Tags as first
> class
> > objects, but this is on Evgenys todo I believe. Since this is not ready
> yet
> > consider the following an example only.
> > >
> > > Assume that the Tag objects has a field xesam:tagName. The return type
> for
> > GetHits is controlled via the session property hit.fields, so if  you
> set
> > this to [xesam:tagName] and do the query
> > >
> > > <request xmlns="
> > http://freedesktop.org/standards/xesam/1.0/query">
> > >   <query content="xesam:Tag">
> > >     <any/>
> > >   </query>
> > > </request>
> > >
> > > GetHits will give you all all known Tag names. If you want the count
> for
> > each tag I see two solutions. Either the ontology should define a field
> > xesam:memberCount or something like that, or you create a new search for
> > each tag like
> > >
> > > <request
> > xmlns="http://freedesktop.org/standards/xesam/1.0/query">
> > >   <query content="xesam:Tag">
> > >     <equals>
> > >       <field name="xesam:tagName"/>
> > >       <string>TAGNAME_HERE</string>
> > >     </equals>
> > >   </query>
> > > </request>
> > >
> > > and simply issue GetHitCount on each search and then close it. This
> should
> > actually be fairly efficient on most backends.
> > >
> > > It should be noted that tagging and tag management as such might be
> hard
> > to implement completely in the search API. The search API is mainly
> > targetted at "search" :-) In XESAM iteration 2 we will focus on a
> metadata
> > management API where such things might be more natural.
> >
> > I just realised that my answer above does not answer your question about
> > mime types and other similar things you might want to list.
> >
> > I think what you ask for is a way to request all different values for a
> > given field. I'm not 100% sure that all implementations can support this
> > effectively. Lucene does not support this AFAIK.
> >
> > Another thing is the use case... In the case of mime types why can't you
> use
> > the conventional ways to get a list of known mime types? Why would you
> > generally want to list all known values of a field? I'm thinking some
> > clustered browsing or something...
>
> The use case would be something like a music program where you would
> like to know what audio types is stored on the hd (mp3, ogg, flac
> etc.) and then add only those as buttons so the user can for example
> select only flac files. Also it could be nice to know how many flac
> files there where before clicking the flac button. In particular
> because the result list might be limited to a certain number of
> results (and because getting the total number (just the count) of flac
> files this way is inefficient ;-)).


In this case I think it is perfectly OK to spawn a search for each supported
audio mime type and issue only a GetHitCount call on each search before you
close it (if we are talking < 10 or so). That should be quite fast on all
backends since there is no real data transmission going on. Moreover if the
hit data is only fetched lazily (like Lucene (and Xapian I believe)) then
the overhead of requesting a few hit counts is really small. I don't know
how fast Tracker would be here, but I suspect plenty fast.

Cheers,
Mikkel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070917/9a8204d9/attachment.html 


More information about the xdg mailing list