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

        <mailto:<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a>>><br>
<br>
        <a href="https://mail.kde.org/mailman/__listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/_<u></u>_listinfo/nepomuk</a><div class="im"><br>
        <<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/nepomuk</a>><br>
<br>
<br>
<br>
<br>
        --<br>
        Vishesh Handa<br>
<br>
<br>
<br></div>
        ______________________________<u></u>___________________<div class="im"><br>
        Nepomuk mailing list<br>
        <a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a> <mailto:<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a>><br></div>
        <a href="https://mail.kde.org/mailman/__listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/_<u></u>_listinfo/nepomuk</a><br>
        <<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/nepomuk</a>><br>
<br>
    ______________________________<u></u>___________________<div class="im"><br>
    Nepomuk mailing list<br>
    <a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a> <mailto:<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a>><br></div>
    <a href="https://mail.kde.org/mailman/__listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/_<u></u>_listinfo/nepomuk</a><div class="im"><br>
    <<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/nepomuk</a>><br>
<br>
<br>
<br>
<br>
--<br>
Vishesh Handa<br>
<br>
</div></blockquote>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>
</div>