On 08/05/15 15:50, Stian Soiland-Reyes wrote:
Great! (I didn't spot this until now! :/ )
I think it looks very similar to commons-rdf-simple -- do you think
some of your simplifications (e.g. in Graph.add()) should be applied
to simple ?
I was trying to just use the external contracts for the RDF terms. If
blank nodes have an accessible global uniqueness of some kind, it is
even-simpler to store as is.
This is the space I was exploring. The same-object-out-as-in would help
for integrating systems and general efficiency (no object churn).
If systemX wants to repmap, it can do it itself.
As I'm looking at defining the hashcodes for COMMONSRDF-14,
would you share any thoughts on why you multiply by 31 here
instead of just returning the uniqueReference() hashCode as-is?
https://github.com/afs/commonsrdf-container/blob/master/src/main/java/org/apache/somewhere/general/BlankNodeImpl.java#L58
No strong reason.
I used Eclipse's "generate hashCode and equals" feature but at time when
there were multiple fields. Eclispe munges by using "31*"
But now I get:
@Override
public int hashCode() {
final int prime = 31 ;
int result = 1 ;
result = prime * result +
((uuid == null) ? 0 : uuid.hashCode()) ;
return result ;
}
I may attempt to parse the identifier and if looks like a UUID string,
parse that. Depends on how COMMONSRDF-6 turns out.
Andy
On 16 April 2015 at 18:46, Andy Seaborne <[email protected]> wrote:
I have a implementation (WIP) as a basis for experimentation, with a slant
towards integration across systems (same implementation/different instance,
or distributed, or different implementation).
https://github.com/afs/commonsrdf-container
Andy
