[Nepomuk] Re: [Basket-devel] Loading Baskets from the command line

Fri Oct 29 21:25:57 CEST 2010

Hi everybody,

Dear Matt,
I have made some improvements (new features and bug fixes) to the
Nepomuk Integration and revised and resubmitted the merge request.

Dear Sebastian,
I have implemented "Indexing Contents of the Actual Notes" as following:
1. Requesting nepomukstrigiservice (via DBus) to index the basket
folder (using indexFolder method).
2. Connecting to indexingStopped signal.
3. Cleaning up the mime-type when received indexingStopped signal.
This way, it even works on my older KDE 4.4.3 at work :)
would you please take a look at the source code on the following URL:
http://gitorious.org/~pakdel/basket/pakdels-basket/blobs/master/src/nepomukintegration.cpp

Dear developers,
I have used threading in the Nepomuk Integration and I will be
grateful if you could check my code :)
http://gitorious.org/~pakdel/basket/pakdels-basket/blobs/master/src/nepomukintegration.cpp

Thanks,
Amir

On Sat, Oct 23, 2010 at 12:36 PM, Amir Pakdel <pakdel at gmail.com> wrote:
> Hi Sebastian,
>
> On Fri, Oct 22, 2010 at 5:18 PM, Sebastian Trüg <trueg at kde.org> wrote:
>> 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?
>>
> I do think so, because we can have things like the priority of the
> mime type, preferred application that handles a mime type and the
> application that added this mime type into the properties of the
> resource (the application that indexed the resource as a specific mime
> type).
>
>>> 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?
>>
> That is a good idea; the simpler the better :D
> This way, Nepomuk should check the application that is invoking the
> indexFile or indexResouce methods. Is it easy to implement?
> Therefore, when invoking application does not match the application
> name stored in RDF, it has to force the index.
>
> Cheers,
> Amir
>
>> Cheers,
>> Sebastian
>>
>>>
>>> I hope I explained my ideas intelligibly  :D
>>>
>>> Cheers,
>>> Amir
>>>
>>> On Mon, Oct 18, 2010 at 5:06 PM, Sebastian Trüg <trueg at kde.org> 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 <trueg at kde.org> 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 <steveire at gmail.com> 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
>>>>>
>>>>
>>>
>>
>