[Nepomuk] Loading Baskets from the command line

[Amir Pakdel]

On Tue, Sep 21, 2010 at 2:21 PM, Sebastian Trüg <trueg at kde.org> wrote:

> On 09/21/2010 12:34 PM, Laura Dragan wrote:
> > On Tuesday 21 September 2010 09:30:19 Sebastian Trüg wrote:
> >> Hi Amir,
> >>
> >> looks like I missed this one. So here goes.
> >>
> >> On 09/14/2010 06:50 PM, Amir Pakdel wrote:
> >>> The last prombems were:
> >>>
> >>>    1.
> >>>
> >>>       I havd to update Krunner Nepomuk plugin to the last version
> >>>
> >>>    2.
> >>>
> >>>       There is a /22rdfsyntaxnsmetadata/ function in /rdf/ which I had
> >>>       to comment out
> >>
> >> Is this something Nepomuk-related? Something that did not work or might
> >> need fixing from my part?
> >>
> >>> I have attached latest version of /src/nepomukintegration.h/ and
> >>> /src/nepomukintegration.cpp/ and I would be greateful if you could take
> >>> look and inform me of any error, bug or requred features.
> >>
> >> Some comments:
> >> - It is recommended to use KUrl(path) instead of
> >>   QUrl::fromLocalFile(path)
> >> - setProperty( "a" ) is very very wrong. :) What you want to do is
> >>   calling addType()
> >> - there is no need to add nfo:FileDataObject type manually. That is
> >>   already handled by strigi and Resource. The same goes for nie:url
> >> - nfo:fileUrl is deprecated in favor of nie:url.
> >> - Please do not use DC. Rather use nie:title.
> >> - use setLabel() instead of setProperty( NAO::prefLabel(),
> >>
> >>> Here is the updated and reformatted testing procedure:
> >>
> >> I am not sure what to do with the explanations below. Is that for manual
> >> testing?
> >>
> >>
> >>> Trüg, do you know why I cannot find tags?
> >>> Laura, what metadata do you suggest to add next?
> >
> > Hi Amir,
> >
> > There are some things which are not completely clear to me.
> > From what I see in the code, you consider a .basket as a note.
> > I see the basket as a container of multiple notes, each distinct
> instances of pimo:Note, each with it's own creation/modification times and
> tags. I'm not sure about the title, as I don't know if you can set the title
> of an individual note in any other way as through formatting in the text.
> And then there are the groups of notes, which I think would make sense to
> capture as RDF as they are structured info as well.
> >
> > @nepomuk What vocabulary offers support for this kinds of containers of
> Things already?
> > As a last resort, you could even make up your own small vocabulary for
> it.
>
> Well, we do have pimo:isPartOf, right?
>
> Cheers,
> Sebastian
>

Hi Laura,
Hi Sebastian,

You are completely right: .basket files represent groups of notes (called
basket) and they contain everything except the notes. The actual notes are
individual files of a variety of types (Image, Text, HTML) in the same
directory and they are addressed in the .basket file.
Nonetheless, I could not define a MIME-Type for the files that really
containing notes, because they already have one! and I could not find a way
to include path of a file as part of the MIME-Type specification. In other
words, what makes an HTML file, a note in "Basket Note Pads" is the
directory that this file resides in.
Consequently, the only solution I could think of, is assigning all the
metadata in the Nepomuk to the .basket file. In fact, the .basket files
contains all this metadata in XML format. Afterwords, as Sebastian said, we
could link notes and baskets in Nepomuk using pimo:isPartOf.
Significance of the MIME-Type is related to the fact that with the right
MIME-Type being set, the search result (in this case the .basket file) is
opened using the appropriate application (Basket Note Pads).
However, I have not tested the effect of pimo:isPartOf! I do not know if a
single note (an HTML file for example) that is a part of a .basket is found
(as a search result) running the note using KRun will open the .basket
(which the note is part of) using the Basket Note Pads or the note file
(using Firefox in tis case).

Any idea or suggestion?

Thanks,
Amir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100923/d6d6a4e5/attachment.htm