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

[Sebastian Trüg]

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