incubator-clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reto Bachmann-Gmür <reto.bachm...@trialox.org>
Subject Re: Clerezza BNode Implementation (was [jira] Commented: (CLEREZZA-395) bnodes mapping in JenaGraphAdaptor should not keep growing with every parsing of rdf files)
Date Mon, 17 Jan 2011 10:35:54 GMT
Hi,

we can certainly improve the current implementation reducing the mapping to bnodes that do
not originate from the jena adapter. But I'm strictly against providing means that would allow
to store or transfer a bnode (reference) without it's context, as this would defeat the purpose
of bnodes.

Cheers,
reto

----- Original message -----
> Hi All,
> 
> I would like to draw your attention to the problems we faced due to
> increasing memory usage needed by the bnode bidirectional mapping.
> Though the RDF specification does not specify how to implement BNode, in
> practice, I think having an implementation where we can assign an
> identifier to a BNode is really useful (see the comments of Rupert
> below).
> 
> Shouldn't we extend the Clerezza BNode implementation with this feature?
> 
> Kind regards
> Hasan
> 
> On Sat, Jan 15, 2011 at 7:58 PM, Rupert Westenthaler (JIRA)
> <jira@apache.org
> > wrote:
> 
> > 
> > [
> > https://issues.apache.org/jira/browse/CLEREZZA-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982150#action_12982150]
> > 
> > Rupert Westenthaler commented on CLEREZZA-395:
> > ----------------------------------------------
> > 
> > I think the only reason why the map is needed is because in Clerezza
> > BNode does not allow to define an ID.
> > 
> > If BNode would have an ID, than one could set this ID to the same
> > value as Node.getBlankNodeId().toString(). If the BNode implementation
> > would than use this ID for the implementation of hash() and equals,
> > than having multiple instances for one and the same blank node in the
> > jena graph should not be a problem anymore and one would no longer
> > need the bidirectional mapping.
> > 
> > BNode could still use the hash() and equals() implementation of
> > java.lang.Object() if no ID is parsed in the constructor so there
> > should be no influence at existing Code.
> > 
> > WDYT
> > Rupert Westenthaler
> > 
> > > bnodes mapping in JenaGraphAdaptor should not keep growing with every
> > parsing of rdf files
> > > 
> > ------------------------------------------------------------------------------------------
> > > 
> > > Key: CLEREZZA-395
> > > URL: https://issues.apache.org/jira/browse/CLEREZZA-395
> > > Project: Clerezza
> > > Issue Type: Improvement
> > > Reporter: Hasan
> > > Assignee: Hasan
> > > 
> > > With every parsing of rdf files free memory is getting less.
> > > The problem seems to lie in the JenaGraphAdaptor class
> > > It has a member:
> > > final BidiMap<BNode, Node> tria2JenaBNodes = new BidiMapImpl<BNode,
> > Node>();
> > > which grows each time a serialized graph get parsed.
> > > My experiments with my test data show
> > > At the end of the 1st parsing: Size of tria2JenaBNodes = 87200
> > > At the end of the 2nd parsing: Size of tria2JenaBNodes = 130800
> > > At the end of the 3rd parsing: Size of tria2JenaBNodes = 174400
> > 
> > --
> > This message is automatically generated by JIRA.
> > -
> > You can reply to this email to add a comment to the issue online.
> > 
> > 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message