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 <[email protected]> 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 <[email protected]> >> 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
