On 11/23/2012 11:17 AM, Vishesh Handa wrote:
On Fri, Nov 23, 2012 at 3:30 PM, Jörg Ehrichs <[email protected]
<mailto:[email protected]>> wrote:
2012/11/23 Marco Martin <[email protected] <mailto:[email protected]>>:
> 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)
>
> 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
[email protected] <mailto:[email protected]>
https://mail.kde.org/mailman/listinfo/nepomuk
--
Vishesh Handa
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
