[Nepomuk] Handling filex:/ urls

[Andrew Lake]

Sebastian Trüg wrote:
> The whole filex:/ situation is a bit weird. I am not sure yet on how to
> solve it. Currently you can ask the removablestorageservice to translate
> the filex:/ URL into a local file:/ URL. It has a DBus method for that
> which is also used in Nepomuk::Resource.
> That said it could make sense to add functionality to Nepomuk::Resource
> to expose the local path of a file.

That would be very helpful.

>
> I think we need to discuss the whole issue with removable media again.
It may be helpful to separate indexing as just one of many potential
paths for adding/updating metadata in the store. Apps will
increasingly become one of the primary mechanisms for storing file
metadata since many primary use cases for metadata will emerge from
the apps, not just from the Search use case served by the indexer.
e.g. NUAO metadata.

> Should the files be indexed?
As long as there are legitimate use cases for storing metadata of
those files, whether technically extractable or not, then it probably
makes sense to allow them to be indexed. Perhaps not indexed by
default, but certainly if the user specifies.

> Should the metadata be removed when unmounting?
I don't think the metadata should be remove.  All the metadata would
have to be recreated once remounted, which might take some time. Plus
non-technically-extractable metadata could not be recreated and would
be lost.  More to the point though is that there are many legitimate
use cases that employ the metadata of even unmounted files. E.g. What
is my most played artist or album, number of movies for my favorite
actor/director, highest rated songs in a genre, etc. This information
can be useful even if the user doesn't actually need to use the
corresponding resource(s) at that moment.  Apps (or the indexer) can
always provide a mechanism that allows the user to explicitly remove
metadata associated with any resource, mounted or not.

> But then we have the same problem again: the fat partition
> you mention is not removable as far as the user is concerned. How to
> detect that?
No need to: If the nie:url property starts with "filex:/" then the app
would be responsible for retrieving the correct url.  A separate
fileExists type of check on the retrieved url will permit the app to
inform the user if a resource is not available for use.  So long as it
is mounted, removable or not, it would be transparent to the user.

It might have been nice if there was a way to retrieve the components
of the correct url via a SPARQL query. Something like a (nie:isPartOf)
nfo:RemovableMedia class that would have uuid and mountPoint (and
maybe isMounted?) properties. These nfo:RemovableMedia properties
could be updated when the device is mounted or unmounted. We might
even be able to do away with "filex:/" altogether: The nie:url
property could just be a pure relative URI that would be resolved to
an absolute URI using the mountPoint property of the associated
RemovableMedia as the base URI. It's a QUrl one-liner:
    correctUrl = mountPointUrl.resolved(nieUrl)

There might even be some general semantic desktop benefits of having
an nfo:RemovableMedia class.

Anyway, as always, thanks for your help Sebastian!

peace and much respect,
Andrew Lake