Dear Nicolas, I would be interested in getting more information about your approach, should I contact you directly,
or could you provide such information by this way?. Best regards Luis Ramos El lun, 9 ene 2023 a las 6:51, Nicholas Car (<n...@kurrawong.net>) escribió: > In case readers of this tread, or the list generally, are interested, we > are testing out a virtual graph access control system that works nicely > with Jena/Fuseki. We create Virtual Graphs that are Named Graphs with no > content but are closures of other Named Graphs that do hold content. In > this way, we can implement fancy access control - multiple users, groups > and roles - to small graph parts, using just standard quad store elements + > administration data holdings. > > So here you would break the larger graph into a Named Graph per governance > unit - whatever your smallest conception of that is - and then build back > up access to multiple Named Graphs via Virtual Graphs. All done in Fuseki > back-end + access control API. > > Happy to share more details if anyone in interested here or directly. > > Cheers, Nick > > -- > Dr Nicholas Car > Data Architect & Knowledge Graph Specialist > Kurrawong AI > n...@kurrawong.net > 0477 560 177 > https://kurrawong.net > > Honorary Lecturer > College of Engineering, Computing & Cybernetics > Australian National University > https://cecc.anu.edu.au/people/nicholas-car > > -- > > > ------- Original Message ------- > On Monday, January 9th, 2023 at 07:01, Andy Seaborne <a...@apache.org> > wrote: > > > > > > On 06/01/2023 15:37, Jonathan MERCIER wrote: > > > > > > Hi Jonathan, > > > > > > Hi Andy, > > > > > > > Could you say somnthing about the usage patterns you are interested > in > > > > supporting? Size of data? Query load? > > > > > > Yes of course, we aims to store Partially uniprot ontology in order to > > > study metabolism on multiple layer > Organism/Gene/Protein/Reaction/Pathway. > > > Thus we will get a huge amount of public and private data (both > academic > > > research and industrial). > > > So we have to use apache shiro to contol who can acces some data (by > > > tenant) > > > > > > Shiro will do the authentication and API security for authorization. > > > > To get the access control on parts of the overall data, do you split the > > data into separate triplestores? Do you use the per-graph access control > > of Jena to get data level security? > > > > The per-graph access control works if (1) you can manage the data that > > way with named graphs and (2) the access control is user, or role, based. > > > > In dayjob, I'm working on another data access control system - we have > > existing data which does not decompose into named graphs very easily and > > the access control rules don't fit user/role bases (Role Based Access > > Control = RBAC). > > > > Attribute Based Access Control (ABAC) can go down to labelling the > > access conditions on individual triples - and also provides of simple > > triple pattern matching (because sometimes, many triples have the same > > label e.g. they have the same property). > > > > The "attribute" part comes from having key/value boolean expressions for > > access conditions, such as "department=engineering & status=employee" > > which can be moved around with the data when sharing across enterprise > > boundaries. > > > > > Currently size of data is estimated around 1 To > > > We will provides a Knowledge release time to time so we will most of > > > time doing read only query and sometime we will push our new release (1 > > > To). > > > > > > Then the full capabilities of RDF Delta may not be needed. Sounds like > > offline database build, copy DB to multiple triple stores behind a load > > balancer. > > > > Full 24x7 update with no single point of failure is nice but it is > > complex. More servers (cost), more admin (more cost!). > > > > Or for a few not-time critical incremental updates, a simple mode for > > RDF Delta is with a single patch manager with a replicated filesystem. > > This is a single point of failure for updates, but the Fuseki replicas > > can provide query service through-out. It is simpler to operate. > > > > Andy > > > > > > There is a Lucene based text index. > > > > Indeed I see this I will take a look, on how to enable lucene with > TDB > > > > > > Also we will take a look to the fuseki API in order to be able to use > it > > > through our python application (more rarely Kotlin) > > > > > > We aims to perform some GeoSpatial query (maybe we would have to make a > > > plugin) in order to have a dedicated algorithm to walk though our > > > knowledge graph > > > > > > > 2) can we deploy a distributed TDB service, in order to have > efficient > > > > query ? > > > > > > > > It can scale sideways with multiple copies of the database kept > > > > consistent across a cluster of replicas using the separate project > (it > > > > is not an Apache Foundation project) that provides high availability > > > > and multiple query > > > > > > > > RDF Delta https://afs.github.io/rdf-delta > > > > Thanks Andy I will take a look >
