Very good. :)
Sorry for not being active anymore. These past 2 weeks I have been =

"working" on my new-born son. Apart from that I am pretty busy with =

OpenLink work. I will try to at least look at the review requests more =

frequently.

On 12/10/2012 02:18 PM, Vishesh Handa wrote:
> Quick update -
>
> Right now the plan is to implement this for 4.11.
>
>
> On Tue, Nov 27, 2012 at 1:53 AM, Sebastian Tr=FCg <trueg@kde.org
> <mailto:trueg@kde.org>> wrote:
>
>     On 11/23/2012 11:17 AM, Vishesh Handa wrote:
>
>
>
>
>         On Fri, Nov 23, 2012 at 3:30 PM, J=F6rg Ehrichs
>         <Joerg.Ehrichs@gmx.de <mailto:Joerg.Ehrichs@gmx.de>
>         <mailto:Joerg.Ehrichs@gmx.de <mailto:Joerg.Ehrichs@gmx.de>>> wrot=
e:
>
>              2012/11/23 Marco Martin <notmart@gmail.com
>         <mailto:notmart@gmail.com> <mailto:notmart@gmail.com
>         <mailto:notmart@gmail.com>>>:
>
>               > On Friday 23 November 2012, Vishesh Handa wrote:
>               >
>               >> <nepomuk:/res/23161f9c-8839-__4de3-bba0-affdd6d654ef>
>               >>         rdf:type
>               >> nmm:MusicPiece
>               >>         rdf:type
>               >> nfo:FileDataObject
>               >>         rdf:type
>               >> nfo:Audio
>               >>         rdf:type
>               >> nie:InformationElement
>               >>         nie:url
>               >> file:///home/vishesh/Music/__where_does_the_good_go.mp3
>               >>
>               >> Storing this URL makes accessing file resources quite
>              convenient. But I
>               >> fear it has been a terrible design decision. By storing
>         the url
>              we face the
>               >> following problems -
>               >
>               > uhm, probably is right, keeping the full file url
>         consistent is a
>              mess,
>               > however...
>               >
>               > a very common use case is in the c++ code, doing
>              Nepomuk2::Resource(file path)
>               >
>               > needing a fast way to obtain the resource associated to a
>              particular file
>               > (like in https://bugs.kde.org/show_bug.__cgi?id=3D310525
>         <https://bugs.kde.org/show_bug.cgi?id=3D310525>)
>               >
>               > otherwise how could be done quickly to have the metadata
>         of a
>              file given we
>               > have the file, and the other way around?
>
>
>         It would be slightly more expensive, but not too hard. One would
>         have to
>         retrieve the resource for each file resource till the root
>         element. So
>         if you give me something like this
>         Resource("/home/vishesh/kde/__src/file.cpp")
>
>         I'll have to do either multiple queries -
>
>         select ?r where { ?r nfo:filename "home" ; nie:isPartOf
>         <rootElement> .
>         } -> homeRes
>         select ?r where { ?r nfo:filename "vishesh" ; nie:isPartOf
>         <homeRes> . }
>         -> visheshRes
>         ..
>         ..
>         or maybe it can be done in one query?
>
>
>     I think so:
>
>     select ?r where { ?r nfo:filename "file.cpp" ; nie:isPartOf [
>     nfo:filename "src" ; nie:isPartOf [ nfo:filename "kde" ... ] ] }
>
>     I am, however, not sure which is faster.
>
>     In general I like the idea to get rid of file URL, a lot actually.
>     This could even mean that you get rid of nie:url alltogether. In the
>     end there is really no need to use nie:url for http or any other
>     remote resource...
>
>     As for your (3): that should actually be fairly simple. I wrote the
>     code, which feels very hacky (not the code itself, but the need for
>     its existance) and it could easily be adapted to only update
>     nfo:filename and nie:isPartOf. Much simpler in the end.
>
>     All in all: +10 from me if you can get the direct file resource
>     access fast.
>
>     Cheers,
>     Sebastian
>
>
>         You get the gist. These all could be cached in memory so it
>         shouldn't be
>         a big problem. This is actually quite analogous to what the
>         kernel does
>         in the file system later, except that it matches inodes to their
>         filename. We will be matching resource uris.
>
>              I'd say retrieving metadata from a file is a "one-time" job
>         of the
>              file-indexer.
>              Afterwards, we should rely on the data inside Nepomuk and
>         only get
>              more once this fails.
>
>              In addition, the nepomuk-core part could offer a convenient
>         method to
>              create the file url for the end-user and also cache this
>         information
>              for a while to speed up the query. I assume its faster to ch=
eck
>              QFile::exists() than creating the url with every query again.
>
>
>         Of course. This all should be transparently handled in the
>         resource class.
>
>              Other than that, I like the idea. It seems there are
>         several problems
>              with remove able media, which doesn't seem to get solved
>         with the
>              current way.
>
>
>         Yeah. I think so as well.
>
>         But it's a BIG change. All the previous data will first need to
>         be ported.
>
>              _________________________________________________
>              Nepomuk mailing list
>         Nepomuk@kde.org <mailto:Nepomuk@kde.org> <mailto:Nepomuk@kde.org
>         <mailto:Nepomuk@kde.org>>
>
>         https://mail.kde.org/mailman/__listinfo/nepomuk
>         <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
>         --
>         Vishesh Handa
>
>
>
>         _________________________________________________
>         Nepomuk mailing list
>         Nepomuk@kde.org <mailto:Nepomuk@kde.org>
>         https://mail.kde.org/mailman/__listinfo/nepomuk
>         <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>     _________________________________________________
>     Nepomuk mailing list
>     Nepomuk@kde.org <mailto:Nepomuk@kde.org>
>     https://mail.kde.org/mailman/__listinfo/nepomuk
>     <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
> --
> Vishesh Handa
>
_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org
https://mail.kde.org/mailman/listinfo/nepomuk