Am 15.02.2011 02:14, schrieb Kingsley Idehen:
On 2/14/11 7:21 PM, William Waites wrote:
* [2011-02-14 15:03:19 -0500] Kingsley Idehen<kide...@openlinksw.com>  écrit:

] If you can graph graph IRIs and scope them to your applications needs,
] what's wrong with that? You don't have to set up multiple ports or
] anything, you just have Graphs that are accessible to users via their
] SQL or WebID style identifiers.

What if there are very many (e.g. millions of) named
graphs? It seems to me that creating and maintaining
the ACLs might be unwieldy and I also wonder about
overhead of checking against the ACLs when some operation
needs to take place.

A practical example might be for library catalogue
records, where each record gets its own graph. Records
from a particular source, say a national library we
might want to mark as read-only for unprivileged users,
whereas user created information like reading lists and
bibliographies should be writeable. A different use case
from the one that spawned this thread since it doesn't
involve completely separate table namespaces. Maybe it
could be done with the clustering, where data held
in one node has the modify bits removed? Else solve
it at the application level...

Cheers,
-w

Best we take all of these scenarios and make a detailed response about
the different options. Clearly, this is becoming very important etc..

Great. However, I'm really wondering a bit why this couldn't be done on the basis of ACLs, i.e., as Kingsley proposed, every user has its own graph, which contains only user specific data, and then there might be a general graph that contains the open data and which maybe also has specific ACLs on parts of this graph that enables write tasks for specific users. Overall, this should enable a user to contribute knowledge to the information service(s) (transitively) and assist thereby to close the information flow lifecycle.

Cheers,


Bob


Reply via email to