clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Minto van der Sluis <mi...@xup.nl>
Subject Re: [VETO] to Code Change 1548545 (was Re: Serializable)
Date Sat, 07 Dec 2013 15:01:56 GMT
Okay I will revert the change.

Any clue how I can then resolve my serialization issue? Is it okay to
add serialization to implementations of Resource, except BNode of course.

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
View raw message