clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <r...@wymiwyg.com>
Subject Re: BNode not serializagle (was Re: [VETO] to Code Change 1548545)
Date Mon, 09 Dec 2013 08:14:23 GMT
Hi Minto

Having Graph to be serializable would indeed not be a problem (also a
ResultSet could be serializable). The problem only arises when BNodes are
serialized independently. When a graph is serialized the serializer ensures
the bnode is unambiguous within the serialized graph only. In fact if we
split an n-triple file and parse each part into a graph, the union of these
two graph may not be equal to the original graph. This is because if there
was a bnode that occurred before and after the line at which we split the
file we will now have two distinct BNodes instead.

Cheers,
Reto


On Sun, Dec 8, 2013 at 4:52 PM, Minto van der Sluis <minto@xup.nl> wrote:

> Hi Reto,
>
> Thanks for the explanation. But there is one thing I don't understand.
>
> Graphs can be serialized to RDF/XML, Turtle and a few other formats. To
> me there is no real difference between Turtle (or the other RDF formats)
> and Java serialization. How do blank nodes get serialized in these other
> cases?
>
> Regards,
>
> Minto
>
>
> Reto Bachmann-Gmür schreef op 6-12-2013 16:59:
> > 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
> >>
> >>
>
>
> --
> 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