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: BNode not serializagle (was Re: [VETO] to Code Change 1548545)
Date Mon, 09 Dec 2013 10:38:46 GMT
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
View raw message