Hi Peter,
I wrote some code to better answer the second part of your email.
> > Besides the SPARQL usecase, here's a simple usecase for wrapping data as
> > RDF:
> >
> > interface Person {
> > String getFirstName();
> > String getLastName();
> > String getDiary()
> > }
> >
> > interface DataBase() {
> > Interator<Person> list();
> > Interator<Person> filterByLastName(String);
> > Interator<Person> filterByFirstName(String);
> > }
> >
> > No the task is to expose this dynamically as RDF (i.e. without
> duplicating
> > the data).
> >
> > Wrapping this with clerezza one would wrap the Person instance in a
> > blanknode, the identity of the BlankNode would depend on the identity of
> > the Person instance. Doing the same with the incubating commons rdf
> > proposal would require keeping a Bidirectional Weak Hashmap of from
> > Blanknode identifiers to Person objects. I don't think many programmers
> > would like to do the latter, so I don't think it is currently a suitable
> > API for exposing arbitrary data using the RDF datamodel.
>
> If there is no single or aggregate primary key for a person, then it
> will not work reliably with any database,
> RDF/Graph/Document/NoSQL/Relational/etc. It works internally in
> Clerezza, in-memory, with the added BlankNode object wrapper, and
> could be mapped using BlankNode.internalIdentifier. It isn't helpful
> to use arguments about not liking a method to imply it is impossible.
>
I did not say that it is impossible, I just say that it takes additional
code and uses additional memory (memory usage can be minimized by using a
bidirectional weak hashmap).
Here I've implemented the simple usecase using Clerezza:
https://github.com/retog/rdfwrapper-example. The actual wrapper class is
here:
https://github.com/retog/rdfwrapper-example/blob/master/clerezza-based-wrapper/src/main/java/org/example/clerezza/based/wrapper/PersonDataBaseGraph.java
.
I think an API should be evaluated by the elegance and efficiency it allows
to implement different usecases. Even if you think that the example is
badly chosen and in reality persons would always come with identifiers I
invite you to implement the same functionality with your API proposal,
after all we should be able to wrap even a crappy API that does not expose
the primary key of the underlying database. Note that the Clerezza Commons
RDF based implementation works with constant memory even if the backend
exposes billions of persons.
I think comparing code and it's properties it's the best way to compare
APIs, so I hope you - or someone else - will accept the invitation.
Cheers,
Reto
