I'm catching up on the history here, so I may or may not understand this point correctly.
As I do understand it, the distinction being made by that method is whether or not some particular Graph takes responsibility for managing the datatypes of literals. Those that manage terms entirely by reference (e.g. TIM) can't and don't at all, but those that manage terms by value at least sometimes (e.g. TDB) might. Sort of. Sometimes. And mixtures are unpredictable and it's not clear what the boolean even means for them. And we have no reason to think that handlesLiteralTyping() is in wide use. I am in favor of using as much as possible only "immediate" RDF notions (e.g. term equality) to formulate any guarantees offered by Graph. It seems to me (IIUC) that handlesLiteralTyping() is exposing what amount to implementation details in a way that is not only unclear and limiting, but could mislead users into writing code that is bound to an impl detail. So +1 to goodbye handlesLiteralTyping(). --- A. Soroka The University of Virginia Library > On Dec 26, 2016, at 12:01 PM, Andy Seaborne <[email protected]> wrote: > > (Tying threads together ...) > > This PR does not cover: > handlesLiteralTyping() > > I'd like to set this on the path to removal mainly because it is unclear and > limiting. It really means "whatever GraphMem" does. It gets complicated when > graph are combined (e.g. union of with and without this capability) or other > composed forms (e.g. inference). I haven't found code that correctly does > that, whatever "correctly" might mean. > > Once, there was a clear distinction between GraphMem, with index values and > database backed graph (indexed terms only). This is no longer true. We have > a variety: in-memory, term only (TIM); disk-backed, some values, looses > duplicate values (TDB); as well as GraphMem (value indexed, does not loose > duplicate values). > > All make sense. > > So how about removing value-related testing the contract of Graph? > The contract tested on Graph is RDF 1.1 -- term equality. > > (Values look like some kind of entailment anyway). > > Andy > > ------------------ > https://github.com/apache/jena/pull/200 > > JENA-1270: Deprecate some methods of Capabilities > > This PR deprecates the following interface methods > > - `addAllowed( everyTriple )` > - `deleteAllowed( everyTriple )` > - `iteratorRemoveAllowed()` > - `canBeEmpty()` > - `findContractSafe()` > ------------------ > > > On 11/12/16 20:17, Claude Warren wrote: >> I think that the permissions layer sets >> boolean addAllowed( boolean everyTriple ); >> and >> boolean deleteAllowed( boolean everyTriple ); >> >> But does not use them directly. >> >> I often wondered what the findContractSafe was. >> >> boolean iteratorRemoveAllowed(); -- not sure of the value here seems like >> most code will attempt the remove and then catch any error. >> >> boolean canBeEmpty(); -- This is used by the contract testing, however it >> could be moved to the graph producer since it is required for the tests. >> >> boolean handlesLiteralTyping(); -- Not sure about the usefulness of this >> method. If the graph does not do literal typing does it change the way the >> higher levels need to work? >> >> Claude >> >> >> On Sun, Dec 11, 2016 at 6:30 PM, Andy Seaborne <[email protected]> wrote: >> >>> Looking at the Capabilities methods, I think there can be some >>> simplification. >>> >>> I also pretty sure no applications actually use the capabilities features >>> but I'm just picking out the safest route in this proposal. Note that >>> GraphReadOnly does >>> >>> Often, the meaning depends on the combination of graphs so for example >>> "iteratorRemoveAllowed" all depends. So it is not reliable. >>> >>> boolean iteratorRemoveAllowed(); >>> boolean canBeEmpty(); >>> boolean handlesLiteralTyping(); >>> >>> This is purely internal: >>> >>> boolean findContractSafe() >>> >>> has one use, for bugs that were resolved(?) pre-Apache according to the >>> comment. I don't know what the contract is. It is used by InfGraph. There >>> is a test but I don't know what it is testing for. >>> PrettyWriterTest.test803804 - it just seems to test that the Abbrev graph >>> response it to and not the root cause. >>> >>> >>> Not used as far as I can determine: >>> >>> boolean addAllowed( boolean everyTriple ); >>> >>> This is used by InfGraphs: >>> >>> boolean deleteAllowed( boolean everyTriple ); >>> >>> though I can't find out what it means. I pretty sure no app uses it (what >>> would it do in response to "false"?) >>> >>> >>> These seem reasonable or are in-use: >>> >>> boolean addAllowed(); >>> boolean deleteAllowed(); >>> boolean sizeAccuruate(); >>> >>> Proposal: >>> >>> deprecate prior to removal: >>> >>> boolean iteratorRemoveAllowed(); >>> boolean canBeEmpty(); >>> boolean handlesLiteralTyping(); >>> boolean addAllowed( boolean everyTriple ); >>> boolean deleteAllowed( boolean everyTriple ); >>> >>> >>> Andy >>> >>> >>> From before: >>> >>> https://lists.apache.org/thread.html/6d26dd787e5678aa3a9b1f1 >>> 7194f44a7204425c0f51667d54f8d6bf7@1378035422@%3Cdev.jena.apache.org%3E >>> >> >> >>
