On 2/15/11 8:20 AM, William Waites wrote:
* [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.
You connect via ODBC using WebID. Meaning, your ODBC DSN and resulting
Connection Strings included WebID based Identification. The Virtuoso SQL
port is set to only accept SSL/TLS connections.
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.
Why would you need to do that based on the above?
A DBMS User inside Virtuoso is associated with a WebID. Thus, you have
SQL Users or SQL Users associated with WebID re. how DBMS object
privileges are handled.
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.
You have to first establish a sense of how Data is Partitioned. Just as
you do in a SQL RDBMS with Tables. In a Property Graph DBMS you should
think of the Named Graphs as Table equivalents. The fact that we
implement the core of this functionality in a single SQL Table that
supports IRIs as native types is a matter for a different layer re. data
storage etc..
You can have Partitions (Named Graphs) with records for #Kingsley that
cover his blogs, wikis etc. You can have another Partition covering HR
records for #Kingsley where property values may include Salary, National
Insurance Number etc..
Re. Data Access, users (based on their SQL userids or WebIDs) will have
access to records based on ACLs scoped to the Named Graphs.
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.
Do you mean Named Graph? Basically, you have an IRI for each of the
Graphs associated with the records/triples you mention above?
Cheers,
-w
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
