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 Tue, 10 Dec 2013 15:38:52 GMT
Hi Minto,

This looks unproblematic.

I was just wondering if we need those serialVersionUID,  I suggest to start
with serialVersionUID 1L (as you did for one of the classes) and then
increment it on any incompatible change. The long serialVersionUID would
only be needed if the class was serializable before, we expect people to
have serialized objects lying around and we want to those objects to remain
compatible with our new version.

Cheers,
Reto


On Mon, Dec 9, 2013 at 11:38 AM, Minto van der Sluis <minto@xup.nl> wrote:

> thanks for the explanation.
>
> Is it okay to make things serializable except for BNodes?
> Like I did here: https://github.com/misl/clerezza/commits/trunk
>
> This time the implementations were made serializeable, not the interfaces.
>
> Regards,
>
> Minto
>
>
> Reto Bachmann-Gmür schreef op 9-12-2013 9:14:
> > 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
> >>
> >>
>
>
> --
> 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