Hi Alessandro Thanks for your ongoing support and feedback.
> On 2/10/12 1:35 PM, Stephen Bayliss wrote: > > I was hoping to supply triple counts, but executing any > SPARQL queries > > (from the Stanbol SPARQL endpoint) on the above is > triggering an out > > of memory exception - do you have any suggestions on this? > (I seem to > > recall that you anticipated that there was likely to be an > issue here.) > > Actually I thought that endpoint wouldn't consider those > graphs at all. > Have you tried using the Clerezza Java API by parsing the > query via the > @Reference QueryParser and issuing it via > TcManager.executeSparqlQuery() ? We have yet to try that via TcManager, though from Olivier's post it sounds like we may still run into issues. > > > Confirmed this is occurring with the above graphs. These are RDF > > graphs in SKOS format, so you should easily be able to find > some data > > to test with (eg fromhttp://www.w3.org/2004/02/skos/). > > Now, I'll need the help of Clerezza and fellow Stanbol developers on > that. I would guess that calling > > mgraph1.addAll(mgraph2) > > when the two MGraphs are both managed by the TcManager and the same > bound TcProvider, will NOT double memory usage. If that is > so, you would > as a matter of fact be having one graph with multiple names. > > @Reto / other Clerezza heads : can you confirm/refute this intuition? > > For reference, the problem is described in the comments of > https://issues.apache.org/jira/browse/STANBOL-426 On this, is there a question over the overall responsibilities of the ontology management API? At a high level (based on my limited knowledge!), within the ontology management API one can * create scopes * create spaces * add ontologies to spaces for ** ontologies persisted outside of KReS ** ontologies persisted directly by KReS; adding those to the underlyng store * remove ontologies from spaces - but this removes the reference and not the underlying graph And using the TcManager one can * remove the graphs from the store ** the outstanding issue from the point of view of our use case being removing graphs where two graph IDs have been minted (and we only know one of the IDs) So I wonder if the ontology management API should be extended to differentiate between ontologies directly managed by the API and those persisted externally; so that for graphs that are directly managed there would be API methods both to deregister these from spaces, and also to deregister these *and* remove them from the store. Then, bringing in your (a)-(e) points from your other post: > (a) the creation of a new graph, as it is now, or > (b) a graph replacement, > (c) a brutal, monotonic addition of all triples to the existing graph, > (d) no action / an exception, or > (e) some sort of sophisticated (DL-consistent?) merge. The ontology management API could be extended to allow some flexibility wrt to these; ie to support replace and merge operations. What do you think? You will of course have a much better perspective than me over what the responsibilities of the various APIs should be so I may be suggesting things here that don't make sense with regards to that. > > On a side note, in order to analyse this thoroughly : what is > the best > tool for monitoring memory usage by Java objects in an Eclipse+Maven > environment, which can also run during JUnit test via Eclipse > ? Are we > still with TPTP ? > > Best Regards, > > Alessandro > > -- > M.Sc. Alessandro Adamou > > Alma Mater Studiorum - Università di Bologna > Department of Computer Science > Mura Anteo Zamboni 7, 40127 Bologna - Italy > > Semantic Technology Laboratory (STLab) > Institute for Cognitive Science and Technology (ISTC) > National Research Council (CNR) > Via Nomentana 56, 00161 Rome - Italy > > > "As for the charges against me, I am unconcerned. I am beyond > their timid, lying morality, and so I am beyond caring." > (Col. Walter E. Kurtz) > > Not sent from my iSnobTechDevice > >
