In my project we want to create a named graph per customer. The customer can then manage triples in their own graph. Using role based permissions we managed to secure the data. Customer A cannot access data of customer B as expected.
But next to triples owned by the customer we also have triples (classes that can be extended by the customer in their own graph and individuals) all our customers need to have read access to. I think these should be added to the default graph?
How should I cope with this setup in my queries? Should we create a role for this default graph that can then be assigned to each customer?
Can you provide me some ideas/solution to this question?
I think there was a previous discussion on this subject so you might want to search the forum and see if you can find it. (I’ll look around and post a link if I can find it). I believe the biggest problem is going to be with your tbox (ontology, axioms, whatever you want to call them). I don’t believe there is any way to separate them based on user access control. The database shares a single view of the ontology. You can restrict the ontology to a named graph and prevent users from updating it but I don’t thing there’s a way to have user A use one ontology and user B user another.
Got it, it was from a previous question you had about something similar
Ok, I've got one idea for you. You could try having a separate database per user and have them query into a shared database using service queries. You'd have to make sure that you have "Reasoning over virtual graphs and SERVICE clauses" turned on which I think is the default. I couldn't find the properties setting for that in the documentation. I don't think the performance should be that bad since you won't have any abox data in the user db and all of it will be at the service endpoint.
To summarize : I add all triples that should be accessible for queries and reasoning to all customers in namedGraphA. All the customers will get a role that allow read access to this graph. Next to this each customer will have its own named graph only accessible to him.
Is it possible to use triples in both named graphs as search criteria and will they be returned if they match as if they were in only one graph? Does it work the same for reasoning?
Or it this approach not supported and should I go for the separate database approach?
Yes, if you have query.all.graphs=true in your stardog.properties file, users can write queries and they will (unless otherwise directed) query over all graphs that user is able to see as if it was one large graph.
If each user was assigned to a role that gave them access to a graph that contained the shared data and ontology, I see no immediate reason why this approach wouldn't work.
I have a general graph to which all customers have access. Then I have a graph per customer. I can query all triples in the general and specific graph. But not the triples of other customers, which is fine.
I think being able to do what your looking for depends on exactly what you're looking to do. You're working with several features that overlap and interact in somewhat subtle ways, schema location, graph based permission, default graph definition, etc. I the one thing that might trip you up is reasoning and your schema which I'm basing on what you said about classes.
You have a couple of options if you'd like users to be able to extend the schema. You can add user's personal graphs to the schema definition but then user B may see unexpected things with reasoning queries because they can't see the schema that is driving the queries. (It isn't really hidden since they can see their effect in the query output and query explanations). It would also be very easy to construct inconsistent schemas since user A has no idea what user B has added.
Another option would be to have separate user graphs for data and schema where the schema would be readable by everyone. That way users would at least be able to see what schema is in effect but they wouldn't be able to correct inconsistencies without coordinating with the user via email or some other method.
You can also make a shared space that is readable and writable by everyone but it would be a free for all.
The last option would be using service queries. That option is the only way I can think of to allow users to apply different schemas to the same data set.
I don't think I'd generally recommend a shared, dynamic, community editable schema but I don't know exactly what your use case is so I thought I'd provide as many options as I could think of.
Let me know what you come up with and how it works out. I'd be interested to hear what your ultimate solution is.