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

[Amir Pakdel]

Hi Sebastian,

Thanks for your reply.

On Mon, Nov 1, 2010 at 12:43 PM, Sebastian Trüg <trueg at kde.org> wrote:
> 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.

I did it async because I wanted to queue up save requests and save
only once when a duplicate save request is encountered in the queue. I
will correct this issue and commit a new version.

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

Shouldn't I use "noteRes.addProperty"?

>
> "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.
Do you mean pimo:partOf ? [1]

Thanks again,
Amir

[1]
http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/#partOf
>
> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>