Re: Beagle's scope
Hi Kevin, 1. RDF Store. I know that the Beagle++ folks had integrated an RDF store into their Beagle modifications. Are there any plans for Beagle proper to include an RDF store? Or does this belong under a separate project? If Beagle will incorporate its own RDF store, should an external application (such as Dashboard) be able to add things to Beagle's RDF store or should it maintain its own RDF store? Actually, there are plans for Beagle to add some RDF to it, but it is more like an (experimental) RDF view on the Lucene indices. So it is not a pure and native RDF store. I think, even if it would be feasable to store RDF into that view, it should not be done or become best practice. Once the first external application starts to use Beagle as an RDF store, other applications may follow. I think, this is not Beagle's scope. The external application should either use a native RDF store running locally as a server, or it may maintain its own store and expose an query interface as Beagle's RDF view. Then, all those application specific RDF stores, as well as the central native store can be queried by applications in a distributed (local) fashion. Regards, Enrico M. ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: suggest: make searches efficient
Hi dBera, So I ask you for suggestions, how to make searches efficient ? though Beagle already arranges results into groups of types (Documents, EMails, Images, ...), it already displays the results inside these groups, so that the user may have to scroll down to find the actual interesting group. What if the first thing being shown are the groups / types of results, along with the number of hits: ++ || | [Icon Docs] [Icon EMails] [Icon Images]| | (3 hits) (20 hits) (124 hits) | || ++ and after selecting a group only the results of this one are shown below. So the first thing you see is in which section of your desktop you have hits. So you would not need to specify the type in the query but can select from the matching ones without being overwhelmed by the hits. Another way is give information where the hits match the query, e.g. if in the subject or the title, the author field or the Text. This is similar to the facated view pointed to by Mikkel, recently. Firstly, for this Beagle would need to extract the Lucene field that matches the query (difficult when the all field is searched), secondly, different filters should use the same field names for the same kind of metadata (the existing beagle ontology issue), and finally, for the field names there need to be a mapping between the beagle field name and a natural language label (even in different languages). Cheers, Enrico M. ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: Building beagle 0.3.2
this may be a somewhat profane question: I'm trying to build beagle 0.3.2 on Ubuntu 7.10. I did not find glib-sharp2 anywhere on the net though. Also, ./configure complains about the missing file mono.pc. Check gtk-sharp2. It could be that glib-sharp2 is packaged with gtk-sharp2. mono.pc should be in some kind of mono-devel package. BTW, *-sharp packages in named as *-cil in Ubuntu (e.g. libglib-cil). - dBera -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: Beagle's scope
Hi Kevin, 1. RDF Store. I know that the Beagle++ folks had integrated an RDF store into their Beagle modifications. Are there any plans for Beagle proper to include an RDF store? Or does this belong under a separate project? If Beagle will incorporate its own RDF store, should an external application (such as Dashboard) be able to add things to Beagle's RDF store or should it maintain its own RDF store? The beagle-rdf-branch in svn has a partial implementation of overlaying an RDF store on beagle data i.e. to say handle RDF queries instead of usual BeagleClient queries. The code in the branch handles all kinds of subject, predicate, object queries. What is missing is to implement a Semweb.Selectable source to add proper RDF flavour to the process. My RDF knowledge is not enough to finish the rest :( The above is an experiment to see if beagle could be mimicked as an RDF store while not designed to be one from ground up. If it works, then any RDF client will be able to query beagle. The other part about storing data is tricky. Again beagle was designed to pull and index information from data, not store data. There is API to add extra data in beagle (search Joe's blog) like tags or additional properties. But for serious applications it is much desirable to have a dedicated store and let beagle index it for you. There has been on-and-off efforts in writing a separate metadata store (possibly a simple sqlite table to start with) but none was completed. 2. Indexing of web apps data. Should Beagle index only desktop/local data or should it also index data from web apps? For example, should Beagle (using web APIs) index my Google Docs? I presonally see no problem in beagle pulling out indexable information from different data sources (local or web). There has been talks about a backend to index GMail mails. A backend to index/query google docs would be a worthwhile addition. - dBera -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: suggest: make searches efficient
Hi, On Jan 8, 2008 3:40 AM, Enrico Minack [EMAIL PROTECTED] wrote: So I ask you for suggestions, how to make searches efficient ? though Beagle already arranges results into groups of types (Documents, EMails, Images, ...), it already displays the results inside these groups, so that the user may have to scroll down to find the actual interesting group. What if the first thing being shown are the groups / types of results, along with the number of hits: ++ || | [Icon Docs] [Icon EMails] [Icon Images]| | (3 hits) (20 hits) (124 hits) | || ++ and after selecting a group only the results of this one are shown below. So the first thing you see is in which section of your desktop you have hits. So you would not need to specify the type in the query but can select from the matching ones without being overwhelmed by the hits. I think shortcuts like these are a good idea, but not at the expense of showing any items at all. You would effectively be adding an extra click for every search, and the tradeoff would be sometimes not needing to scroll. So basically what I'm saying is that I like the idea, but we shouldn't *require* clickthrough to get at the results. Another way is give information where the hits match the query, e.g. if in the subject or the title, the author field or the Text. This is similar to the facated view pointed to by Mikkel, recently. Yeah, I like this idea. Joe ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
Re: suggest: make searches efficient
Ie cluster/facet extraction on the result set? It is far from trvial to do in an efficient and scalable way, but it can be done... The website I linked to have 10M items in the index. Its easy to do such fancy data-mining tricks for a webserver. On a desktop, such fancy things might cause annoying CPU spikes. But still this needs to be implemented to see how far can it work. Aside the question of scalability, I am wondering how to display this in the beagle-search GUI ? Without cluttering the interface. - dBera -- - Debajyoti Bera @ http://dtecht.blogspot.com beagle / KDE fan Mandriva / Inspiron-1100 user ___ Dashboard-hackers mailing list Dashboard-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/dashboard-hackers
