* [2011-02-15 10:09:03 +0100] Bob Ferris <z...@elbklang.net> écrit: ] ] 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.
It might be possible to do it that way, but would mean quite a lot of rearranging of things. Let me explain. So first when I say user in this context I mean the user for ODBC authentication. A web application (that has its own idea of service users) connects to the database as a relatively unprivileged user, i.e. it has read-only access to some large number of graphs, and read-write access to some other graphs. A maintenance script or batch process run by an admin would connect to the database as a privileged user for example to update the otherwise read-only graphs from some new source data. Even if we were to arrange to push user authentication down towards the database, so that virtuoso has some idea of the web service users and credentials for the, they still have multiple graphs and can create new ones. Ultimately this is a design choice we made to use the store a bit like a document database: for each "object" (in the ORM-like sense) there is a graph with statements pertaining to that object - at least a SBCD but often other kinds of statements are included. So in Bibliographica, every book has a graph, every author has a graph, every service end-user has a graph (which amounts to a FOAF profile) and every reading-list has a graph. Cheers, -w -- William Waites <mailto:w...@styx.org> http://river.styx.org/ww/ <sip:w...@styx.org> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
