[Nepomuk] Brainstorming: Metadata Sharing

[Sebastian Trüg]

On 06/30/2010 07:17 PM, Richard Dale wrote:
> On Wed, Jun 30, 2010 at 12:30 PM, Sebastian Trüg <trueg at kde.org> wrote:
>> The more I read your discussion the more I am convinced that caching
>> remote metadata locally is a problem. The two reasons are as Artem said:
>>
>> 1. What to copy? In the worst case the whole graph is connected and we
>> loose information unless we copy everything.
>> 2. How to make sure the data is up-to-date?
>>
>> Still, let me draft you the ideas we came up with at the last Nepomuk
>> workshop:
>> We wanted to allow users to share certain resources or bits of metadata
>> with other users. This information would then be copied to the
>> interested parties, marking the origin in the enclosing graphs. The
>> resource URIs would not be changed since they are unique (this is a
>> theoretical assumption that sadly does not hold in reality since the
>> QUuid implementation creates a lot of duplicates - more about that
>> below). In the case of files, however, the nie:urls would be a special
>> kind of URL - something like telepathy:/<user>/<path-on-users-host> - so
>> KIO could handle those automatically if they appear as search results.
>>
>> Another approach for resource URIs was to have a layer between local and
>> remote data that adds username information to the URIs. An example would be:
>>  nepomuk:/res/<UUID>
>> becomes
>>  nepomuk:/<username>@<something>/res/<UUID>
>> when copied to other hosts.
>> This would solve the UUIDs not being unique problem which keeping the
>> nepomuk:/ protocol and allowing a simple converting in both ways.
>>
>> So maybe a middle way would be: we only copy the metadata that we "need"
>> or "want". We never copy strigi extracted data (since we can recreate
>> that once we have the file) but when copying the file we copy metadata
>> the other user created - like ratings or comments, but also relations to
>> other things. These things will then be referenced with URIs as above
>> and can be fetched on demand.
>> Thus, there would be no need to store all related resources. And in case
>> we want to use those resources in queries we query the remote client again.
> I am interested in this problem, and I think the meaning of triples
> exchanged over p2p can change. For instance, if my list of favourite
> singles of the 1970s includes 'Chirpy, Chirpy, Cheep, Cheep' by Middle
> of the Road, then to me it is an absolute fact that this song is the
> best. If I send my list of favourite 1970's songs to someone else then
> they may disagree. It is only a recommendation from myself. So
> normally RDF reification would handle this, but I don't think that
> reification is regarded as a good idea within Nepomuk. You could just
> add someone else's recommendations to a graph, but I'm not sure how
> that would capture the meaning of 'Richard thinks Chirpy, Chirpy,
> Cheap, Cheap is great'.

it does not at the moment but that is the plan: allow multiple graphs
from different people storing the same information like in this case the
rating. Then you can do things like: "this is your rating, this is what
other people think on average, this is what Richard thinks."

Cheers,
Sebastian