Hi Amir, On 10/19/2010 01:51 PM, Amir Pakdel wrote: > Two more ideas came into my mind: > 1. Something could be added to anthologies that indicates the priority > of mime-types, like the "priority" property of "magic" XML element > that is used in the XML files that define mime-types. This way, > multiple mime-types of a resource can be prioritized.
I think this is a problem with the way mime types are represented today: as strings. Do you think a hierarchy of mime types would solve that problem, too? > 2. Nepomuk::Indexer could have a method to set a flag in resources > that prevents "automatic indexing" or at least prevents resources from > being indexed using strigi, or some thing like a "lock" or a "do not > change" hint or so. This way, a specific application would take full > responsibility for the resource. Moreover, indexFile, indexResource > and other method could have another parameter "force" that defaults to > false and the application that is responsible for the resource could > call these methods with force=true this is an interesting idea. How could we put that in RDF? Maybe a simple property on the indexing graph which states the application handling this specific file? Cheers, Sebastian > > I hope I explained my ideas intelligibly :D > > Cheers, > Amir > > On Mon, Oct 18, 2010 at 5:06 PM, Sebastian Trüg <[email protected]> wrote: >> Sounds like a good idea. However, I will still find a more generic way >> in addition to that. >> Stay tuned for more info. >> Cheers, >> Sebastian >> >> On 10/15/2010 07:38 PM, Amir Pakdel wrote: >>> Hi Sebastian, >>> >>> On Fri, Oct 8, 2010 at 12:00 PM, Sebastian Trüg <[email protected]> wrote: >>>> Hi guys, >>>> >>>> On 10/07/2010 09:25 PM, Amir Pakdel wrote: >>>>> Hi everybody, >>>>> >>>>> On Wed, Oct 6, 2010 at 8:47 PM, Stephen Kelly <[email protected]> wrote: >>>>>> Matt Rogers wrote: >>>>>> >>>>>>>> The second solution is more appealing, but I would rather get a >>>>>>>> working version with what we have got now. Therefore, I will go with >>>>>>>> the first suggestion. >>>>>>>> >>>>>>> >>>>>>> We actually have thought about interfacing with Akonadi for data >>>>>>> storage/caching. If we do that, would we get Nepomuk integration for >>>>>>> "free" as well? >>>>>> >>>>>> Just an FYI about this: >>>>>> >>>>>> I changed how kjots stores data so that it can use Akonadi for access to >>>>>> the >>>>>> notes. >>>>> >>>>> Although I have read all I could find about Nepomuk and Akonadi, I >>>>> still don't know what Akonadi does exactly and how it interacts with >>>>> Nepomuk! >>>>> Could anyone please help me with that? >>>> >>>> AFAIK Akonadi stores blobs of data and provides a few APIs to convert >>>> these blobs into something useful. One prominent example is mime data. >>>> Nepomuk is a graph of information and thus, completely different. >>>> Akonadi more or less duplicates all its information in Nepomuk so one >>>> can perform searches on the data and create relations. This is a weird >>>> situation as the info is stored twice but we cannot change that at the >>>> moment. Maybe in the future we can merge both projects - who knows. >>>> >>>> So to me it does not make much sense to store notes in Akonadi as you >>>> need to copy them to Nepomuk anyway. Thus, you would need to implement >>>> the data handling twice: once the Akonadi blob and once the Nepomuk >>>> resource data. >>>> >>>>>> >>>>>> http://dot.kde.org/2010/02/17/kjots-takes-advantage-innovations-kde- >>>>>> development-platform >>>>>> >>>>>> KJots accesses the notes as Mime documents (KMime::Message objects) from >>>>>> Akonadi. Akonadi stores the notes in mime format in maildir containers >>>>>> (one >>>>>> note per file). The mime format could also be used to store the images in >>>>>> the note directly in the note, but I haven't got around to doing that >>>>>> (though there is API for it I think). >>>>>> >>>>>> http://www.faqs.org/rfcs/rfc2387.html >>>>>> >>>>>> The way Akonadi stores the notes is irrelevant to the application. They >>>>>> could just as easily be in mbox format (one single file for a group of >>>>>> notes). The application just uses the KMime::Message objects that Akonadi >>>>>> returns. >>>>>> >>>>>> Even if you don't make basket use Akonadi yet it could make sense to >>>>>> store >>>>>> the notes as mime messages and use KMime to (de)serialize them. >>>>>> >>>>>> All the best, >>>>>> >>>>>> Steve. >>>>>> >>>>> >>>>> I hope I found a solution for opening note files with Basket: >>>>> Suppose there is a basket in >>>>> ~/.kde/share/apps/basket/baskets/basket106 which has a note in a file >>>>> called note1.html and the metadata in Nepomuk is as following: >>>>> >>>>> $ nepomukcmd query "select ?r where { ?r nie:url >>>>> <file:///~/.kde/share/apps/basket/baskets/basket106/note1.html> . }" >>>>> <nepomuk:/res/00473b7a-4ac9-4223-b8d3-dee3d24631c1> >>>>> Total results: 1 >>>>> Execution time: 00:00:00.3 >>>> >>>> Where did that URL come from? Normally Nepomuk should only contain >>>> absolute URLs. >>>> >>>>> $ nepomukcmd query "select ?a where { >>>>> <nepomuk:/res/00473b7a-4ac9-4223-b8d3-dee3d24631c1> nie:mimeType ?a . >>>>> }" >>>>> "application/x-basket-item"^^<http://www.w3.org/2001/XMLSchema#string> >>>>> Total results: 1 >>>>> Execution time: 00:00:00.1 >>>>> >>>>> >>>>> Now in Nepomuk::SearchRunner::run, we could get the service that >>>>> should run this resource and then tell the KRun to use it, like the >>>>> following: >>>>> >>>>> QString mimetype = >>>>> res.property(Nepomuk::Vocabulary::NIE::mimeType).toString(); >>>>> KService::Ptr preferredService = >>>>> KMimeTypeTrader::self()->preferredService( mimetype ); >>>>> >>>>> KRun *newApp = new KRun(url, 0); >>>>> newApp->setPreferredService( preferredService->desktopEntryName() ); >>>>> >>>>> I hope it works without changing anything else. >>>>> Sebastian, would you please take a look? >>>> >>>> This is a good idea for a quick intermediate solution. :) >>>> Very nice. All you would have to do is set the mimetype on the notes >>>> manually. The only problem left is that strigi would add the html >>>> mimetype, too. But we can handle that by indexing the baskets manually. >>>> >>>> For the latter I need to make some API public which I need to do anyway. >>>> Can we meet on IRC? I am in #nepomuk-kde on freenode >>>> >>>> Cheers, >>>> Sebastian >>>> >>>>> >>>>> Cheers, >>>>> Amir >>>>> >>>> >>> >>> Sorry for being late. Since I could not find you on IRC (Friday 15 Oct >>> 17:30 GMT) I am writing this. >>> >>> IMHO the following scenario would work fine: >>> 0. ~/.kde/share/apps/basket should not be indexed automatically. >>> >>> 1. We keep the current code that adds the metadata of the basket and >>> its notes into the Nepomuk and sets notes as parts of the basket. >>> 2. Ask the Nepomuk::Indexer to index notes using Indexer::indexFile method >>> 3. Develop a slot (for example resetMimetype) that clears mimetype of >>> the notes and sets it back to application/x-basket >>> 4. connect Nepomuk::indexingDone to the newly developed slot in basket >>> (resetMimetype) >>> >>> This way, the only thing that would be changed in the Nepomuk it that >>> the indexingDone signal is implemented and it is supposed to be >>> emitted. >>> >>> >>> Please let me know your opinion. >>> >>> >>> Cheers, >>> Amir >>> >> > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
