clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@apache.org>
Subject [VETO] to Code Change 1548545 (was Re: Serializable)
Date Fri, 06 Dec 2013 15:59:17 GMT
A sidenote: I think we changed to Git and I'm surprised SVN still accepts
commits.

But to the main issue, I ask you to revert your recent commit.

BNodes MUST NOT be Serializable and as such Resource MUST NOT implement
Serializable.

Technical reason:

Clerezza Storage provider must guarantee that the Graphs express the same
meaning over time, they are not required to ensure they remain isomorphic
over time. Clerezza must allow storage provider to remove redundancy in the
graph. For this implementation are not required to keep any
referenceability to BNodes once the BNode instance is (respectively once
all equal BNode instances are) eligible for garbage collection.


Example:
MGraph g = tcManager.createMGraph(...)
{
 BNode b1 = new Bnode();
 g.add(new TripleImpl(b1, FOAF.givenName, new PlainLiteralImpl("Peter"));
 BNode b2 = new Bnode();
 g.add(new TripleImpl(b2, FOAF.givenName, new PlainLiteralImpl("Peter"));
 //here the store must keep the two triples as we might add additional
triples
 //that make the graph non-lean
 //e.g.
 //g.add(new TripleImpl(b1, FOAF.familyName, new
PlainLiteralImpl("Miller"));
 //g.add(new TripleImpl(b1, FOAF.familyName, new PlainLiteralImpl("Smith"));
}
//here as b1 and b2 are no longer reachable the storage provider might
leanify
//the graph, so it will contain only one triple and one BNode

The above no longer holds if b1 and b2 are serializable, in this case
having the variable become eligible for garbage collection (i.e. become
unreachable) no longer guarantees that nobody will try to access that BNode
at a later time, as it may have been serialized and reside somewhere on
disk. If Bnodes are serialize implementation would typically have to assign
internal IDs to the BNodes and keep them forever. The fact that BNode are
truly Blank is however one of the strengths and advantages of the Clerezza
API as it allows what is described above as well as storage provider
wrapping backends (such as sparql) that do not provide BNode IDs.

Cheers,
Reto





On Fri, Dec 6, 2013 at 3:52 PM, Minto van der Sluis <minto@xup.nl> wrote:

> I created and solved issue CLEREZZA-850 for this.
>
> BTW which repository is leading SVN of Git?
>
> Regards,
>
> Minto
>
> Minto van der Sluis schreef op 6-12-2013 12:41:
> > Hi folks,
> >
> > Is there a specific reason why serializable is hardly used in Clerezza?
> > Most particularly classes/interfaces like:
> >
> >     Resource
> >     Expression
> >
> > Why do I need this?
> >
> > I am using Apache Wicket to show the results of a sparql query in a
> > pageable data view. For this I created a Wicket model for
> > SolutionMapping. In Wicket models need to be serializable.
> > SolutionMapping (particularly HashMapSolutionMappin) is serializable
> > since it exteds the serializable HashMap. The key (Variable) and value
> > (Resource) types unfortunately are not serializable.
> >
> > Is this by design I could a have a go at making them  serializable?
> >
> > Regards,
> >
> > Minto
> >
> >
> >
>
>
> --
> ir. ing. Minto van der Sluis
> Software innovator / renovator
> Xup BV
>
> Mobiel: +31 (0) 626 014541
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message