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

[Sebastian Trüg]

On 11/01/2010 10:53 AM, Amir Pakdel wrote:
> 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"?

nope, you are doing addType in the line before. That is enough. :)

>>
>> "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]

yes.

Cheers,
Sebastian

> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>