Hi Sergio I would like to have one method less in the BlankNode Interface and one method less in the RDFFactory interface so I don't want to make BlankNodes more prominent.
Of course every implementation to add whatever method it wants, its the additional methods that reduce the freedom (and also caused quite some discussions about their consequences and interpretation (beside the discussions that I started)). I think at first the API should not model more than the common subset of all implementations. For going beyond that and even beyond the RDF spec there need to be very strong reasons imho. Cheers, Reto On Mon, Apr 20, 2015 at 12:39 PM, Sergio Fernández <[email protected]> wrote: > Hi Reto, > > you're right, this project is about compatibility. But in that business > some times you have to keep aside dogmatisms for the best of the project. > We did that quite well with Peter and Andy in the early phases of this > project, and I fear we have entered a dangerous path that is going nowhere. > > I'm always of the thinking that cooperation is the key of success. Here we > have (had) for discussing the internal implications of the decision in the > design of our API. But where I do have an opinion about the API is as a > potential user; and from that point of view I have to say I found > completely useless the latest discussions about blank nodes. In RDF blank > nodes are just local identifiers, they should not be that prominent in the > API as you want, and I'd expect to give freedom to each store > implementation. > > Normally in our world the popularity of libraries/APIs provides a pretty > good So if necessary, I'm willing to conduct a open survey of RDF in Java > to put in the right place some aspects we've been discussing, probably for > too long, in the last weeks. > > Cheers, > > > On Mon, Apr 20, 2015 at 2:16 PM, Reto Gmür <[email protected]> wrote: > > > On Wed, Apr 15, 2015 at 12:10 AM, Peter Ansell <[email protected]> > > wrote: > > > > > 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. > > > > > > > I think this project is about allowing a degree of compatibility between > > different implementations, what you describe is a possible but by no > means > > necessary condition for that purpose. A minimum compatibility would allow > > that the same code can be run against different implementations (e.g. > > different triple stores) without allowing instances from various > > implementations to be mixed at runtime. I'd prefer to have a higher level > > of compatibility allowing to use instances of different implementations > in > > the same runtime, and being able to move triples and nodes from one > > implementation to the other, for this purpose I raised the issue to > define > > identity criteria and hascodes. Even for this higher level of > compatibility > > it is not necessary for BlankNodes to expose an ID. > > > > Cheers, > > Reto > > > > > > -- > Sergio Fernández > Partner Technology Manager > Redlink GmbH > m: +43 6602747925 > e: [email protected] > w: http://redlink.co >
