Sorry I missed this discussion. The permissions system recognises 4 actions: read, create, update and delete. thus distinguishes between creating new triples and updating existing ones.
On Mon, May 4, 2015 at 4:35 PM, Rob Vesse <[email protected]> wrote: > Perhaps an EnumSet and a single method: > > EnumSet<AccessMode> getAccessModes(); > > Assuming you can do bitwise operators on enum members in Java: > > enum AccessMode { > Read, > Append, > Delete > }; > > So a Read/Write graph returns: > > EnumSet.of(AccessMode.Read, AccessMode.Append, AccessMode.Delete); > > A read only graph returns: > > EnumSet.of(AccessMode.Read); > > An append only graph returns: > > EnumSet.of(AccessMode.Append); > > etc. > > Rob > > On 30/04/2015 21:55, "Andy Seaborne" <[email protected]> wrote: > > >On 30/04/15 21:33, Claude Warren wrote: > >> So if a graph allows adding but not deleting how does it respond to the > >> isReadOnly() method? > > > >My question was how important/frequent is that case vs the importance of > >the question "is this graph mutable"? If it is rare, then designing > >around the uncommon cases to disadvantage the common leads to a > >confusing design. > > > >isReadOnly() is false is the graph can change in any way. > >Of course, we could have a default method in Graph that is > > > > default boolean isReadOnly() > > { return !addAllowed() && !deleteAllowed() ; } > > > >but a proliferation of methods isn't helpful either. > > > > Andy > > > >> > >> > >> > >> On Thu, Apr 30, 2015 at 9:13 PM, Andy Seaborne <[email protected]> wrote: > >> > >>> On 29/04/15 20:58, Andy Seaborne wrote: > >>> > >>>> On 29/04/15 18:17, Claude Warren wrote: > >>>> > >>>>> I use the following: > >>>>> > >>>>> addAllowed() is used by contract tests to determine if triples can > >>>>>be > >>>>> added. Also, permission system sets this based on the users > >>>>>permissions. > >>>>> canBeEmpty() is used by the contract tests to determine if the > >>>>>deleteAll > >>>>> methods should return an empty graph. > >>>>> > >>>> > >>>> When is this ever false? Inference graphs? > >>>> > >>>> (This is not used in the current codebase as far as I can see) > >>>> > >>>> deleteAllowd() same use as addAllowed() > >>>>> iteratorRemoveAllowed() -- this is handy to know before the remove is > >>>>> attempted. > >>>>> > >>>> > >>>> This isn't honoured everywhere IIRC. You're only looking in > >>>>jena-core. > >>>> > >>>> sizeAccurate() -- this is used by the contract testing to determine > >>>>if > >>>>> delete and add should alter the number of records reported. I am > >>>>>also > >>>>> looking at adding some hash joining capabilities and knowing if the > >>>>>sizes > >>>>> are accurate may make a difference. But that is all future stuff. > >>>>> > >>>> > >>>> FYI: > >>>> https://github.com/afs/quack > >>>> > >>>> These I don't use and can see being removed: > >>>>> > >>>>> findContractSafe() -- I don't know what this one means and have never > >>>>> used > >>>>> it. > >>>>> handlesLiteralTyping() -- This was used but obviously sine all > >>>>>graphs now > >>>>> have to support literal typing this can be removed. > >>>>> > >>>> > >>>> and presumably not addAllowed(boolean), deleteAllowed(boolean) > >>>> > >>>> (I find the boolean form unhelpful because they don't say what triples > >>>> can and can not be add/deleted.) > >>>> > >>>> so let's try removing: > >>>> > >>>> addAllowed(boolean) > >>>> deleteAllowed(boolean) > >>>> findContractSafe() > >>>> handlesLiteralTyping() > >>>> > >>> > >>> which leaves: > >>> > >>> boolean sizeAccurate(); > >>> boolean addAllowed(); > >>> boolean deleteAllowed(); > >>> boolean iteratorRemoveAllowed(); > >>> boolean canBeEmpty(); > >>> > >>> Is it better to have > >>> > >>> isReadOnly() > >>> > >>> and not addAllowed(), deleteAllowed() > >>> > >>> I can imagine append-only graphs but is it worth having two calls when > >>>the > >>> common case is read-only vs writable. > >>> > >>> And if it is just > >>> > >>> boolean sizeAccurate(); > >>> boolean isReadOnly(); > >>> boolean iteratorRemoveAllowed(); > >>> boolean canBeEmpty(); > >>> > >>> Should we just pull these up into Graph/GraphBase? > >>> > >>> I have only found two uses of Capabilities in non-test, non-passing-on > >>> cases. I didn't find any evidence of passing capabilities around. > >>> > >>> One use of getCapabilities() in the isomorphism tester GraphMatcher - > >>>it > >>> needs sizeAccurate()). > >>> > >>> One use in RDF/XML output; Abbreviated uses findContractSafe but it > >>>prints > >>> a warning if used and no one has asked about that in a long while so > >>>I'm > >>> guessing it does not happen any more. > >>> > >>> Strangely - I can't find uses of iteratorRemoveAllowed() except in > >>>tests. > >>> > >>> Andy > >>> > >>> > >>> > >>>> Andy > >>>> > >>>> > >>>>> On Wed, Apr 29, 2015 at 4:14 PM, Andy Seaborne <[email protected]> > >>>>>wrote: > >>>>> > >>>>> On 29/04/15 16:04, Claude Warren wrote: > >>>>>> > >>>>>> I have no problem retiring FileGraph > >>>>>>> > >>>>>>> Capabilities is another issue. I have used it and it is used in > >>>>>>> several > >>>>>>> places in the contract tests where we have to know if the graph > >>>>>>> supports > >>>>>>> transactions and the like. I find it useful. In addtion the > >>>>>>> information > >>>>>>> containd in the capabilities is often not easily discoverable (if > >>>>>>>at > >>>>>>> all). > >>>>>>> > >>>>>>> > >>>>>>> Transactions aren't in the Capabilities interface. > >>>>>> > >>>>>> Which aspects of the Capabilities interface? Some looks to be out > >>>>>>of > >>>>>> date > >>>>>> (findContractSafe); some are not the right question > >>>>>> (handlesLiteralTyping) > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Wed, Apr 29, 2015 at 9:45 AM, Andy Seaborne <[email protected]> > >>>>>>> wrote: > >>>>>>> > >>>>>>> Claude's email about FileGraph prompted me to think for Jena3: > >>>>>>> > >>>>>>>> > >>>>>>>> What can be removed? > >>>>>>>> What can be simplifed? > >>>>>>>> > >>>>>>>> Even while keeping the current APIs, there is going to stuff that > >>>>>>>> isn't > >>>>>>>> used, isn't used much, or even gets in the way. For > >>>>>>>>maintainability, > >>>>>>>> effectively unused features are noise and risk needing to maintain > >>>>>>>> contracts that users don't actually use. > >>>>>>>> > >>>>>>>> Some things that come to mind in jena-core: > >>>>>>>> > >>>>>>>> FileGraph [*] > >>>>>>>> Capabilities > >>>>>>>> GraphTransactionHandler > >>>>>>>> > >>>>>>>> and with advocacy: > >>>>>>>> > >>>>>>>> RDFReaderF, RDFWriterF (with RIOT integration; caution for > >>>>>>>> RDF/XML) > >>>>>>>> > >>>>>>>> Some places where interfaces don't seem to add anything: > >>>>>>>> > >>>>>>>> LiteralLabelImpl > >>>>>>>> > >>>>>>>> (actually the whole LiteralLabel thing is worth looking at - maybe > >>>>>>>> we can > >>>>>>>> pull the whole thing into into Node_Literal itself) > >>>>>>>> > >>>>>>>> AnonIds - maybe leave in the RDFAPI (they cross the boundary) but > >>>>>>>> internall bNodes can be a couple of longs for their state (a UUID > >>>>>>>>in > >>>>>>>> other > >>>>>>>> words, not a UID). > >>>>>>>> > >>>>>>>> Andy > >>>>>>>> > >>>>>>>> [*] > >>>>>>>> In Java8, the app, or library code, could do this better as: > >>>>>>>> > >>>>>>>> update(()->{ > >>>>>>>> ... graph changes ... > >>>>>>>> } > >>>>>>>> > >>>>>>>> and update() does the on-disk backup stuff. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >> > >> > > > > > > > -- I like: Like Like - The likeliest place on the web <http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
