2007/9/17, Anders Rune Jensen <<a href="mailto:anders@iola.dk">anders@iola.dk</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 9/17/07, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com</a>> wrote: > 2007/9/17, Mikkel Kamstrup Erlandsen <<a href="mailto:mikkel.kamstrup@gmail.com">mikkel.kamstrup@gmail.com </a>>: > > 2007/9/17, Anders Rune Jensen <<a href="mailto:anders@iola.dk">anders@iola.dk</a>>: > > > > > 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=" > <a href="http://freedesktop.org/standards/xesam/1.0/query">http://freedesktop.org/standards/xesam/1.0/query</a>"> > >   <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="<a href="http://freedesktop.org/standards/xesam/1.0/query"> http://freedesktop.org/standards/xesam/1.0/query</a>"> > >   <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 ;-)).</blockquote><div> 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. </div> </div>Cheers, Mikkel