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

Sebastian Trüg trueg at kde.org
Mon Nov 1 10:13:10 CET 2010 

Hi Amir,

funnily enough you do exactly what was explained in "You are doing it
wrong"[1]: you are trying to move the thread to itself. This, however,
it not possible since the thread you want to move it to is not running
yet (and for another reason that I forgot).

Also the run method is called in the new thread. There is no need to
start anything async in there. Just do the work, ie. what doUpdate()
does now.

"basketRes.setProperty( Soprano::Vocabulary::RDF::type(),
Soprano::Vocabulary::PIMO::Note() );"
this will overwrite all other types. You can just remove that line.

"basketRes.setProperty( Soprano::Vocabulary::NIE::url(), basketUri );"
No need. This is done internally anyway.

"basketTag.setProperty( Soprano::Vocabulary::NAO::prefLabel(), tagName );"
just use setLabel()


Are you using nie:isPartOf to group subnotes? If so better use
pimo:isPartOf.

Cheers,
Sebastian

[1]
http://labs.trolltech.com/blogs/2010/06/17/youre-doing-it-wrong/#more-1608

On 10/29/2010 09:25 PM, Amir Pakdel wrote:
> 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
>>>>>>
>>>>>
>>>>
>>>
>>
>

More information about the Nepomuk mailing list