[Nepomuk] Brainstorming: Metadata Sharing

Artem Serebriyskiy v.for.vandal at gmail.com
Tue Jun 29 16:24:34 CEST 2010


1) What relations should be copied ? E.g. music file has a relation
nao:condutcor that points to some nco:contact. When copying resource,that
represents this file should we copy nco:contact too ? If we don't copy
nco:contact,  then - as I see - when searching for "All music files that has
XX as conductor" we must execute this query in almost all remote host - more
exactly in all remote hosts we hold uri to via some remote
music_file_resource.

* Sorry for my english. I mean that because we didn't copy nco:contact fist
name and second name, then to search for all music files that has "Ennio
Morricone" as conductor we must:
a) determinte all remote resources that represents a music file
b) execute query in every such remote host.

2) May be I understand your idea wrong, but it seemes useless for me - even
the resource type is a relation.

3) Then we should execute query in every available remote host?

On Tue, Jun 29, 2010 at 5:31 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
>



-- 
Sincerely yours,
Artem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100629/d0b96b58/attachment-0001.htm 


More information about the Nepomuk mailing list