On 2/15/11 3:16 AM, Sebastian Tramp wrote:
On Mon, Feb 14, 2011 at 03:03:19PM -0500, Kingsley Idehen wrote:
To ask from another direction:
** Is it possible that user1 uses a SQL / SPARQL query on one set of
triple tables and user2 uses other triple tables? **
- With SQL / SPARQL query I mean an SQL query of the form "SPARQL
{SPARQL}" as we use it in OntoWiki via ODBC.
- With triple tables, I mean the virtuoso DB.DBA.RDF_* tables. In
addition to that, these two OntoWiki intances create their own
tables.
In the Property Graph Engine (RDF Quad Store).
You have a Single Table that supports reference values via IRIs as
native Types. Thus, you partition your data via Named Graphs.
Yes, but then you have to make sure
1. that these graph IRIs are unique
2. that no app can see/read/modify graphs from another one
In a scenario where users can create graphs via this application, both
requirements are not so easy to achieve:
1. if you want to import schema graphs (sioc, skos, ...) and you create these
in both apps, we have a problem.
2. Since we do not know, which IRIs are used, we cant create generic AC rules.
This means the app need to protect its graphs on there own which requires
DBA rights and no one can hinder a app with DBA right to look into other
apps graphs.
If you want to make many RDF_QUAD tables per user, this requires lower
level changes that will ultimately require RDF_QUAD to port mappings
re. /SPARQL etc.. A lot of work for no application management gain,
ultimately.
Yes, thats what we want. RDF_QUAD tables per user so that a DBA users
SPARQL queries are mapped to DB.user1.RDF_* tables instead of DBA ones.
We can call this feature "Multiple parallel Quad Tables" if you
want. (Norman Heino told me that he talked to Orri Erling 2-3 years
ago about that.)
The idea isn't new, practical value of the implementation is the main
issue.
I hope that my answer explain the practical value for this. I think this
is needed to level up virtuoso to an everyday use database which is also
suitable for multiple small/medium knowledge bases and which can replace
mysql for some usecases on my servers.
At the moment, we have to start 5 virtuoso instances for 5 OntoWiki
deployments to avoid conflicts with graph IRIs. This was the sticking
point of this thread and I know now, that there is currently no way to
do it better (but I hope this can be part of LOD2 development :-) )
As I said to William, we need to make a more detail response and guide
re. application partitioning.
Re. ontoWiki we have a long standing todo re. user partitioning. Thus,
we might even be able to use our fixes in this area as
guidance for you.
Kingsley
best regards
Sebastian Tramp
--
Regards,
Kingsley Idehen
President& CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
