Andy, Thanks for sharing the details with us, now it all makes sense. Now I am able to ask the next question ;-)
What is memory vs. processing cost comparison for different dataset wrappers (GraphStore, Model, InfModel, etc)? In other words, I assume that one should keep a single dataset instance throughout whole application since the instance is heavy resource vise. But what about the wrappers? For example, If I want to work with a GraphStore across an application, should I create new GraphStore instance over the single datasource each time I need such a wrapper or should I have a single GraphStore instance and reuse it across the whole application? The same question holds for each other type of the datasource wrapper also (Model, InfModel, ...). The rationale for the question is as follows: If memory as well as processing cost is negligible then instantiation of a wrapper is voluntary and depends on one's programming style. If memory cost is high while processing cost is low then the overall cost is reduced to memory allocation only, and one should optimize according to the particular system architecture. If memory cost is low while instantiation processing cost is high then one should have a single instance that is initialized once and kept in memory during whole application life time. Since we are dealing with wrappers, the fourth case, memory as well as processing cost are high, is probably not possible. Milorad >________________________________ > From: Andy Seaborne <[email protected]> >To: [email protected] >Sent: Monday, March 19, 2012 5:00 PM >Subject: Re: is GraphStore deepcopy or a facade? > >On 19/03/12 10:18, Milorad Tosic wrote: >> Hi, >> >> I am trying to understand how NamedGraphs work in Jena+TDB and how to use >> SPARQL for the purpose. The API that I found as an eventual candidate that >> would fit the task is GraphStore. My initial understanding was that >> GraphStore is a kind of facade on top of the TDB store that should be used >> in a case of incoming UPDATE query if there is a chance that the query >> eventually deals with NamedGraphs. However, the test gives somewhat >> unexpected results (suggesting that the GraphStore may actually be deep copy >> of the store?). >> >> What am I missing here? I am afraid that my understanding of the conceptual >> model of NamedGraphs in Jena+TDB is not correct. How should the SPARQL query >> processing be organized in the case of TDB store working with named graphs? >> >> >> Regards, >> Milorad > > >Hi there, > >There is a problem in this line: > >> GraphStore graphStore = GraphStoreFactory.create(m_triplestore) >>; > >which takes a model, without knowing the dataset it comes from, and asks for a >GraphStore. A temporary dataset is created which in actually another >in-memory dataset unconnected to the original m_dataset. > >Datasets are the unit of collections of graphs. > >Ideally, try to use datasets everywhere and think of the models as views into >the dataset. If you want to work across the model container, work on a >dataset. > >But, beware, there is second trap waiting for you :-) > >TDB does not know about empty graphs - if it has no triples, as far as TDB is >concerned, it does not exist. CREATE GRAPH is a no-op for TDB. There is no >separate management of graphs, only the triples and quads tables. No entries >=> does not show up in > >SELECT ?g WHERE { GRAPH ?g { } } > >(you don't need DISTINCT) > >GraphStore is actually just a wrapper around the dataset - it's stateless but >it works on datasets. > > Andy > > >
