On 14 April 2015 at 01:33, Reto Gmür <[email protected]> wrote: > On Sat, Apr 11, 2015 at 1:05 PM, Peter Ansell <[email protected]> > wrote: > >> On 11 April 2015 at 22:24, Reto Gmür <[email protected]> wrote: >> > Sorry for the delay... >> > >> > On Fri, Mar 27, 2015 at 11:56 AM, Andy Seaborne <[email protected]> wrote: >> > >> >> Project proposals? Pointers please. >> >> >> > >> > From: http://wiki.apache.org/incubator/ClerezzaProposal >> > >> > Clerezza provides: >> >> >> >> - An API modeling the W3C RDF standard without any vendor specific >> >> additions. >> >> >> >> I'm quite certain that the API is the part of clerezza which is most >> used. >> > >> > >> >> and you have evolved to something for Clerezza that is not interface >> >> based, which, as already commented (no response from you BTW) is a >> >> roadblock for some. >> > >> > I managed to reply on that before my holidays, but just to be clear: >> Using >> > interfaces is no roadblock for clerezza, its just a question which API >> > design is better. Using Blanknode identifiers is likely to be a >> roadblock. >> >> What exactly is it about BlankNode.internalIdentifier that is >> incompatible with the Clerezza assumptions? Have you explored ways >> that Clerezza could generate such an internalIdentifer just to satisfy >> the interface even if, hypothetically, it only internally supports >> continuous in-memory BlankNodes, with "==" equality, rather than >> ".equals" equality. >> > There is no "==" equality, the onyl equality that matters is > node1.equals(node2), internally this can be done comparing a string > identifier. That's also why constant memory parsers are also possible > without exposing the identifier in the public API.
This entire project is about not relying on internal fields for .equals, essentially. Ie, we are moving away from any implementation specific methods that rely on internal field access (or other internal methods) and instead creating a Public API to replace them. Thanks, Peter
