On 06/30/2010 07:17 PM, Richard Dale wrote: > On Wed, Jun 30, 2010 at 12:30 PM, Sebastian Trüg <[email protected]> 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 _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
