Mailing-List: contact dev-help@clerezza.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@clerezza.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: <52A495C6.4080708@xup.nl>
References: 
 <CALvhUEVG5PTFkEOZZ5uJ_Uw98gbvPyP=SaXC3LZn6mpx0fwb9g@mail.gmail.com>
	<52A495C6.4080708@xup.nl>
Date: Mon, 9 Dec 2013 09:14:23 +0100
Message-ID: 
 <CALvhUEX-qHZ-0+onHpi4-L6xMxZSdEOwi47PXsw+pWrzYESycg@mail.gmail.com>
Subject: Re: BNode not serializagle (was Re: [VETO] to Code Change 1548545)
From: =?ISO-8859-1?Q?Reto_Bachmann=2DGm=FCr?= <reto@wymiwyg.com>
To: dev@clerezza.apache.org
Content-Type: multipart/alternative; boundary=001a1134cea865422004ed1595e2

--001a1134cea865422004ed1595e2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=FCr schreef op 6-12-2013 16:59:
> > A sidenote: I think we changed to Git and I'm surprised SVN still accep=
ts
> > 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 sa=
me
> > meaning over time, they are not required to ensure they remain isomorph=
ic
> > 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 onc=
e
> > all equal BNode instances are) eligible for garbage collection.
> >
> >
> > Example:
> > MGraph g =3D tcManager.createMGraph(...)
> > {
> >  BNode b1 =3D new Bnode();
> >  g.add(new TripleImpl(b1, FOAF.givenName, new PlainLiteralImpl("Peter")=
);
> >  BNode b2 =3D 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 a=
re
> > 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 Clerezz=
a?
> >>> 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 valu=
e
> >>> (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
>
>

--001a1134cea865422004ed1595e2--