You're more than welcome :)
On Mon, Jan 24, 2022 at 3:41 PM Vilnis Termanis <vilnis.terma...@iotics.com> wrote: > > Hi Martynas, > > Thank you very much for the suggestion (and additional information > out-of-band). > I've been having a look at LinkedDataHub and will come back to you > with some questions, if you don't mind. > > Regards, > Vilnis > > On Fri, 21 Jan 2022 at 15:26, Martynas Jusevičius > <marty...@atomgraph.com> wrote: > > > > WebAccessControl ontology might be relevant here: > > https://www.w3.org/wiki/WebAccessControl > > We're using a request filter that controls access against > > authorizations using SPARQL. > > > > On Fri, Jan 21, 2022 at 4:13 PM Vilnis Termanis > > <vilnis.terma...@iotics.com> wrote: > > > > > > Hi, > > > > > > For a SPARQL query via Fuseki, we are trying to restrict visibility of > > > groups of triples (each with multiple subjects) dynamically, in order > > > to allow for generic queries to be executed by users (instead of > > > providing tinned ones). > > > > > > Looking at the available ACL mechanisms in Jena/Fuseki, I assume > > > storing each of these groups as a distinct graph might be the way > > > forward. (The expectation is to be able to support 10^5 or higher > > > number of these.) > > > > > > I.e.: Given a user (external to Fuseki, e.g. presented via shiro via > > > LDAP/other), only consider triples from the set of graphs 1..N during > > > the query. (Where the allowed list of 1..N graphs is to be looked up > > > at the point of the query.) > > > > > > From my limited understanding, some potential routes are: > > > > > > a) jena-fuseki-access - Filters triples at storage level via "TDB Quad > > > Filter" support in TDB. > > > However, the configuration of allowed graphs per user is static at > > > runtime. > > > > > > b) jena-permissions - Extends the SPARQL query engine with an Op > > > rewriter which allows a user-defined evalulator implementation to > > > allow/deny access to a graph/triple, given a specific user/principle. > > > (The specific yes/no evaluation responses are cached for the duration > > > of a query/operation.) > > > However, this can only applied to a single graph as it stands. > > > > > > c) Parse & re-write the query to e.g. scope it using a fixed set of > > > "FROM" clauses. From some minimal testing (with ~200 FROM clauses) > > > this does not appear to perform well (compare to a tinned query which > > > explicitly restricts access via knowledge of the ontologies involved). > > > I appreciate that maybe having a large list of FROM clauses is an > > > anti-pattern. > > > > > > My questions are: > > > > > > 1) Does filtering to a set of subset of graphs (from a large set of > > > graphs) to restrict access sounds like a sensible thing to do? (Note > > > that each of these graphs would contain a set of multiple subjects - > > > i.e. we are not trying filter by specific predicate/object values.) > > > > > > 2) Would extending either jena-fuseki-access to support the > > > user-graph-list lookup dynamically OR extend jena-permissions to work > > > at dataset level be sensible things to do? > > > > > > 3) If the answer to either of (2) is yes - I'd be interested in > > > getting a better understanding of what would be involved to gauge the > > > size/effort of such an extension. I have had a look codebases for the > > > aforementioned projects, but my knowledge of TDB/ARQ/etc is very > > > limited. (We'd potentially be interested in taking this on, time & > > > priorities permitting.) > > > > > > I didn't know which mailing list to send this to but I thought the > > > users list would probably be a better starting point. > > > > > > Regards, > > > Vilnis > > > > > > -- > > > Vilnis Termanis > > > Senior Software Developer > > > > > > e | vilnis.terma...@iotics.com > > > www.iotics.com > > > > -- > Vilnis Termanis > Senior Software Developer > > m | +44 (0) 7521 012309 > e | vilnis.terma...@iotics.com > www.iotics.com > > The information contained in this email is strictly confidential and > intended only for the parties noted. If this email was not intended > for your use, please contact Iotics. For more on our Privacy Policy > please visit https://www.iotics.com/legal/
