[Nepomuk] Brainstorming: Metadata Sharing

[Vishesh Handa]

I was planning to have #3 ( no synchronization ), but I think #1 would be
better. #2 is a compromise between the two that won't really help us.
Relations are what define resources. Without them, they are just unique
identifiers.

#1 seems interesting, but we'll have to implement a way to synchronize the
offline metadata when the user comes online are performs another search.
There is the added problem of privacy. Suppose user B contains A's metadata,
and A marks its metadata as no longer sharable, we should probably delete
A's metadata from B, but B could possible prevent this or make copies.

As the whole object being a resource problem. Yes, we'll have to copy
everything about the object as well. There is no way to avoid it, but
typically every resource contains a maximum of 20 properties, so it
shouldn't be that much.

BTW, it would be better to have resource uris in the form of
nepomuk:/telepathy/whatever instead of telepathy:/nepomuk/whatever. There
are loads of checks in the Nepomuk Core and services which make decisions
based on a url's scheme. So it would be better to stick to "nepomuk".

*What relations should be copied?*
One option would to be copy all the relations ( shouldn't be too much ), but
I think we should only copy the relations returned by the result of a query.
That way it would be a lot easier to determine what relations other users
are allowed to access, and would prevent copying or relations the user
doesn't want to share. Copying only the transfered relations would require
less requests.
*
P2P Network*
That was the whole idea behind metadata sharing. Hopefully I'll be able to
implement some form of it. :)
*
Who to query?
*One option is that we have select queries, where the user chooses the
contact before performing the query. The other is to perform the query on
all the contacts ( might be a little expensive )

*Sharing others metadata *
User A has a some fragment of B's metadata. If C queries A, should it also
return B's metadata? If yes, how do we deal with privacy?
*
Forwarded Queries?*
Should one contacts forward it's query to it's other clients? If we forget
about privacy for a second, this would be amazing. This would be ideal for
storing a huge knowledge base on multiple systems.

Just some random ideas

- Vishesh Handa

On Tue, Jun 29, 2010 at 7:01 PM, Daniele E. Domenichelli <
daniele.domenichelli at gmail.com> wrote:

> On 06/29/2010 12:57 PM, Artem Serebriyskiy wrote:
> > Can you please describe your idea in more detail?
> > What information is stored localy ?
> > And how to perform queries ? For example:
> > "Select all resources that have a label <string literal> "
> > and
> > " Select all [music]files that has a <NCO:Contact | where this
> nco:contact
> > is stored localy> as author".
>
>
> Well, I have 3 different scenarios in my mind:
>
>
> 1: during synchronization both resources and relations are copied:
>
> * resources on remote nepomuk server can be stored locally, but, in
>  order to avoid conflicts between uri, the name can be replaced, for
>  example:
>    from:  nepomuk:/<resource>
>    to:    telepathy:/contact/<name>/nepomuk/<resource>
>           (or nepomuk:/telepathy/contact/<name>/<resource>)
>
> * relations can be copied modifying the name of the subject and of the
>  object using the new name, for example
>    from:  nepomuk:/<resource1>
>           <relation>
>           nepomuk:/<resource2>
>    to:    telepathy:/contact/<name>/nepomuk/<resource1>
>           <relation>
>           telepathy:/contact/<name>/nepomuk/<resource2>
>
> In this way:
> * queries can be done locally even if the contact is offline
> * the uri for a resource will always be unequivocal (but it might
> require some relation to represent, for example that a resource
> representing a file on my pc corresponds to a resource that represents
> the same file on my contact's pc
> * When the contact is online you could use dbustubes to execute (and to
> listen for changes to) a specific query
>
>
> 2: Same as 1, but only resources are copied
>
> In this way:
> * queries executed when the contact is online can return results using
> both local and remote nepomuk server (using dbustubes to execute queries
> on the remote server), but queries executed when the contact is offline
> can return results using local server only.
> * The local database will contain less informations, so it will probably
> be smaller and faster, but the times for remote queries will be probably
> longer due to network latency
>
>
> 3: No synchronization at all
>
> In this way queries on remote server can be executed only if the contact
> is online.
>
>
>
> In all cases queries will just be a normal query that returns some
> resources of type "nepomuk:/" and some resources of type
> "telepathy:/contact/<name>/nepomuk/", but they might need to be executed
> both on local and on remote servers using dbustubes (and resource from
> remote servers must be modified to represent the name of the contact
> that created it)
>
>
>
> Cheers,
>  Daniele
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100630/8b4967e3/attachment.htm