[Nepomuk] Brainstorming: Metadata Sharing
Vishesh Handa
handa.vish at gmail.com
Mon Jun 28 21:12:29 CEST 2010
Hello Oszkar
On Tue, Jun 29, 2010 at 12:14 AM, Oszkar Ambrus <aoszkar at gmail.com> wrote:
> Hi Vishesh,
>
> On 28 June 2010 18:50, Vishesh Handa <handa.vish at gmail.com> wrote:
> > Metadata sharing implies that we should be able to see other people's
> > metadata and have it on are own system. Sebastian suggested that we store
> > user information ( who owns which statements ) as graph metadata. That's
> > totally feasible, and maybe we could also store the permission settings
> as
> > graph metadata.
>
> I'm thinking of permissions settings similar to how you share stuff
> through Samba.
> You can share your stuff with guests (i.e. everyone, without
> authentication), with all known users (stored locally) or with a
> subset of existing users.
> The list of users could be stored locally as RDF and then, similarly
> to what Sebastian suggested, statements can be annotated with the
> graph meta-data to specify privileges.
>
Yes. I had something similar in mind.
>
> > I'm not too sure how we would choose whose metadata to store our on
> system
> > or why we would need to do that.
>
> As for whose meta-data to store, would you like to go with a
> high-level protocol, such as Jabber? So no low-level stuff?
>
Forget about Jabber. I think it would be better to go with Telepathy.
Daniele [0] is working on "Telepathy Tubes and File Transfer in KDE", and it
would be a lot better to support multiple protocols via Telepathy instead
just supporting Jabber. Once his project is complete we should be able to
export a Dbus interface to other contacts, so that greatly simplifies the
problem of how to connect/transfer stuff between 2 machines.
Please look at the attached conversation.
> Because, as I understood, the RDF repository is going to be exposed
> through HTTP, so you could connect to anyone's repository and just
> insert their address in the graph metadata of the statements you store
> locally.
>
No, I don't think we should expose it via HTTP. ( Might be problematic )
There is a project in the playground called nsqd (Nepomuk Social Query
Daemon ), which does something similar. I'll take a look at it.
- Vishesh Handa
[0] http://blogs.fsfe.org/drdanz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/nepomuk/attachments/20100629/3ffc02f0/attachment-0001.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chat
Type: application/octet-stream
Size: 430 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/nepomuk/attachments/20100629/3ffc02f0/attachment-0001.dll
More information about the Nepomuk
mailing list