[Nepomuk] Why store file urls?
Sebastian Trüg
trueg at kde.org
Mon Dec 10 13:25:58 UTC 2012
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üg <trueg at kde.org
> <mailto:trueg at kde.org>> wrote:
>
> On 11/23/2012 11:17 AM, Vishesh Handa wrote:
>
>
>
>
> On Fri, Nov 23, 2012 at 3:30 PM, Jörg Ehrichs
> <Joerg.Ehrichs at gmx.de <mailto:Joerg.Ehrichs at gmx.de>
> <mailto:Joerg.Ehrichs at gmx.de <mailto:Joerg.Ehrichs at gmx.de>>> wrote:
>
> 2012/11/23 Marco Martin <notmart at gmail.com
> <mailto:notmart at gmail.com> <mailto:notmart at gmail.com
> <mailto:notmart at 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=310525
> <https://bugs.kde.org/show_bug.cgi?id=310525>)
> >
> > 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 check
> 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 at kde.org <mailto:Nepomuk at kde.org> <mailto:Nepomuk at kde.org
> <mailto:Nepomuk at kde.org>>
>
> https://mail.kde.org/mailman/__listinfo/nepomuk
> <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
> --
> Vishesh Handa
>
>
>
> _________________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org <mailto:Nepomuk at kde.org>
> https://mail.kde.org/mailman/__listinfo/nepomuk
> <https://mail.kde.org/mailman/listinfo/nepomuk>
>
> _________________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org <mailto:Nepomuk at kde.org>
> https://mail.kde.org/mailman/__listinfo/nepomuk
> <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
> --
> Vishesh Handa
>
More information about the Nepomuk
mailing list