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

[Amir Pakdel]

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