thank you for the link Claude, looks indeed like a very useful addition to a standard implementation. In particular when combined with an enhanced admin UI I would think.
Marco On Fri, Nov 15, 2019 at 1:33 PM Claude Warren <cla...@xenei.com> wrote: > Marco, > > The permissions layer [1] is a separate module that wraps graph and model > implementations with permissions checking. It can use Shiro (or whatever > Fuseki uses). > > Basically, it uses the dynamic proxy mechanism to intercept "interesting" > calls to graph and model to filter out triples that should not be seen by > the user. It operates at 2 distinct levels: You can limit user access to > an entire graph/module or you can limit access to specific triples within > the graph/module. > > I was recently wondering if anybody actually, (outside of the project I > worked on, used it in production. I got an answer when I got a query about > how to do some specific task from a company that was utilizing it for a > number of implementations. > > Claude > > [1] https://jena.apache.org/documentation/permissions/index.html > > On Fri, Nov 15, 2019 at 11:24 AM Marco Neumann <marco.neum...@gmail.com> > wrote: > > > when you say as an afterthought you refer to shiro? to define permissions > > functionality in a TTL configuration for high granularity would indeed be > > nice. why not do it somewhat similar to how it's done in mainstream RDBMS > > with SQL system tables? > > > > > > On Fri, Nov 15, 2019 at 11:07 AM Claude Warren <cla...@xenei.com> wrote: > > > > > I would like to see the permissions functionality baked into the > standard > > > implementations rather than wrapped around as an afterthought. > However, > > if > > > that can't be done or is just more overhead than we want when > permissions > > > are not in use then I would hope that we will continue to use > interfaces > > to > > > define the objects in the API. > > > > > > I think we should also look at Rya (https://rya.apache.org) and > Commons > > > RDF > > > (https://commons.apache.org/proper/commons-rdf/index.html) to see if > > there > > > is anything we can learn from them. > > > > > > On Thu, Nov 14, 2019 at 8:09 PM Aaron Coburn <acob...@apache.org> > wrote: > > > > > > > I would be very interested in discussing the high level Java API and > > how > > > it > > > > could be simplified. > > > > It might also be worthwhile to look into the overall package/jar > > > structure. > > > > This will help for both OSGi and JPMS support. > > > > > > > > Regarding the Java14/JPMS target, I assume this means that the Jena > > code > > > > can be compiled and run on a Java14 environment and/or used on the > > module > > > > path in a JPMS-enabled application (and *not* that all downstream > > > > applications must use one of the newer Java runtimes). That is, would > > the > > > > compiler target and source still be Java8? > > > > > > > > Cheers, > > > > Aaron > > > > > > > > On Wed, 13 Nov 2019 at 14:18, Andy Seaborne <a...@apache.org> wrote: > > > > > > > > > I'd like to start a discussion on where the project might go longer > > > term. > > > > > > > > > > This can be specific areas, overall design, about project > processes, > > > > > anything. > > > > > > > > > > If we are going to do a major change, Jena4, what preparation for > > that > > > > > can be done? (e.g. deprecation and signalling in Jena3, before the > > > > > change happens). > > > > > > > > > > Realistically, Jena4 means having Jena3 and Jena4 in parallel. > Jena4 > > > > > need not be that big - we can have Jena5 etc. > > > > > > > > > > I'll put some technical points in a separate email. > > > > > > > > > > I would put on the list: > > > > > > > > > > * How has the world changed? What should the project produce? > > > > > * Target audience: for developers of Jena, while Jena3 is for > users. > > > > > * Target: Java14, JPMS. > > > > > * Clear-up not easily done with perfect compatibility. > > > > > * Simpler. There are APIs and packages entangled due to history. > > > > > > > > > > To the lurkers :-) > > > > > > > > > > Feedback and specific feature requests are welcome. But before you > > "go > > > > > shopping", you may wish to factor in that every feature needs > effort > > to > > > > > do it. The better place to be is that an application can get what > it > > > > > needs to do, not whether the Jena system has every feature > built-in. > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > -- > > > I like: Like Like - The likeliest place on the web > > > <http://like-like.xenei.com> > > > LinkedIn: http://www.linkedin.com/in/claudewarren > > > > > > > > > -- > > > > > > --- > > Marco Neumann > > KONA > > > > > -- > I like: Like Like - The likeliest place on the web > <http://like-like.xenei.com> > LinkedIn: http://www.linkedin.com/in/claudewarren > -- --- Marco Neumann KONA
