<br><br><div class="gmail_quote">On Tue, Jun 29, 2010 at 11:31 PM, Vishesh Handa <span dir="ltr">&lt;<a href="mailto:handa.vish@gmail.com">handa.vish@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

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


<br>#1 seems interesting, but we&#39;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&#39;s metadata, and A marks its metadata as no longer sharable, we should probably delete A&#39;s metadata from B, but B could possible prevent this or make copies. <br>


<br>As the whole object being a resource problem. Yes, we&#39;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&#39;t be that much.<br>

</blockquote><div><br>I am not so sure about it. some resource has properties that points to another resource. If we copy music_file_resource, should we copy nco:contact that represents it&#39;s conductor ? If yes, then should we copy the friends of this conductor ? If no, then how to execute query &quot;Find all music that was written by any of the friend of this &lt;contact_name&gt;&quot; ? If yes, then should we copy friends of a friends of a ..... of a friends of a contact ? Where/when should we stop ?<br>

<br>About revoking permissions. The copyright of the local copy of the shared metadata must be well defined. If license for these metadata are not free, then I must be asked for conformation of acceptance of this licence. If licenes is free, then the local copy of metadata are mine metadata and I( and most peoples too) defenetly would not allow delete something in my computer without my permission.<br>

<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>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&#39;s scheme. So it would be better to stick to &quot;nepomuk&quot;.<div class="im">

<br>
<br><b>What relations should be copied?</b><br></div>One option would to be copy all the relations ( shouldn&#39;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&#39;t want to share. Copying only the transfered relations would require less requests.<br>

</blockquote><div><b><br></b>Even copying some part of the relations will not solve some of our problems. I dont see any way to check that <br>1) The stored copy of the metadata are correct( May be remote user has just fixed some very serious bugs  in his metadata? And we still have version with bugs)<br>

2) No more resources appeared in the any of the remote hosts Nepomuk storages that match our query<br>without performing a query in the remote host. This means that for any `global` query we should always execute this query in all available remote hosts. Or we must be satisfied with probably-obsolete-or-incorrect metadat we have stored localy. In this case caching any of the relations localy seems useless.<br>

</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><b>P2P Network</b><br>That was the whole idea behind metadata sharing. Hopefully I&#39;ll be able to implement some form of it. :)<br>

<b><br>Who to query?<br></b>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 )<br>


<br><b>Sharing others metadata </b><br>User A has a some fragment of B&#39;s metadata. If C queries A, should it also return B&#39;s metadata? If yes, how do we deal with privacy?<br><b><br>Forwarded Queries?</b><br>Should one contacts forward it&#39;s query to it&#39;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. <br>


<br>Just some random ideas<br><font color="#888888"><br>- Vishesh Handa</font></blockquote><div><br><b>Forwarded Queries</b>  are automaticaly ( by [good] design) included into<b> P2P</b> network. There are problems with permisions(<b>Sharing others metadata ),</b> but I have heard about P2P network with this feature. I will try to remeber and/or google it.<br>

<br>All above is IMHO and may be incorrect ))<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5"><br>
<br>
<div class="gmail_quote">On Tue, Jun 29, 2010 at 7:01 PM, Daniele E. Domenichelli <span dir="ltr">&lt;<a href="mailto:daniele.domenichelli@gmail.com" target="_blank">daniele.domenichelli@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>On 06/29/2010 12:57 PM, Artem Serebriyskiy wrote:<br>
&gt; Can you please describe your idea in more detail?<br>
&gt; What information is stored localy ?<br>
&gt; And how to perform queries ? For example:<br>
&gt; &quot;Select all resources that have a label &lt;string literal&gt; &quot;<br>
&gt; and<br>
&gt; &quot; Select all [music]files that has a &lt;NCO:Contact | where this nco:contact<br>
&gt; is stored localy&gt; as author&quot;.<br>
<br>
<br>
</div>Well, I have 3 different scenarios in my mind:<br>
<br>
<br>
1: during synchronization both resources and relations are copied:<br>
<br>
* resources on remote nepomuk server can be stored locally, but, in<br>
  order to avoid conflicts between uri, the name can be replaced, for<br>
  example:<br>
    from:  nepomuk:/&lt;resource&gt;<br>
    to:    telepathy:/contact/&lt;name&gt;/nepomuk/&lt;resource&gt;<br>
           (or nepomuk:/telepathy/contact/&lt;name&gt;/&lt;resource&gt;)<br>
<br>
* relations can be copied modifying the name of the subject and of the<br>
  object using the new name, for example<br>
    from:  nepomuk:/&lt;resource1&gt;<br>
           &lt;relation&gt;<br>
           nepomuk:/&lt;resource2&gt;<br>
    to:    telepathy:/contact/&lt;name&gt;/nepomuk/&lt;resource1&gt;<br>
           &lt;relation&gt;<br>
           telepathy:/contact/&lt;name&gt;/nepomuk/&lt;resource2&gt;<br>
<br>
In this way:<br>
* queries can be done locally even if the contact is offline<br>
* the uri for a resource will always be unequivocal (but it might<br>
require some relation to represent, for example that a resource<br>
representing a file on my pc corresponds to a resource that represents<br>
the same file on my contact&#39;s pc<br>
* When the contact is online you could use dbustubes to execute (and to<br>
listen for changes to) a specific query<br>
<br>
<br>
2: Same as 1, but only resources are copied<br>
<br>
In this way:<br>
* queries executed when the contact is online can return results using<br>
both local and remote nepomuk server (using dbustubes to execute queries<br>
on the remote server), but queries executed when the contact is offline<br>
can return results using local server only.<br>
* The local database will contain less informations, so it will probably<br>
be smaller and faster, but the times for remote queries will be probably<br>
longer due to network latency<br>
<br>
<br>
3: No synchronization at all<br>
<br>
In this way queries on remote server can be executed only if the contact<br>
is online.<br>
<br>
<br>
<br>
In all cases queries will just be a normal query that returns some<br>
resources of type &quot;nepomuk:/&quot; and some resources of type<br>
&quot;telepathy:/contact/&lt;name&gt;/nepomuk/&quot;, but they might need to be executed<br>
both on local and on remote servers using dbustubes (and resource from<br>
remote servers must be modified to represent the name of the contact<br>
that created it)<br>
<div><div></div><div><br>
<br>
<br>
Cheers,<br>
 Daniele<br>
_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Sincerely yours,<br>Artem<br>