On 04/06/13 13:44, David Jordan wrote:
Andy, I am curious, I have not evaluated this. Are there any inherent
performance consequences when working with a union of graphs? For
example, is there a need to do multiple lookups as opposed to one
when searching for resources?
Union Default Graph is quite cheap nowadays - single access per triple
pattern, and it needs to ensure set of triples (not a bag of triples)
semantics but it now has detailed knowledge of TDB storage to know
duplicates are (due to the index structure) adjacent in the streams of
matches of a triple pattern. That duplicate suppression is cheap. It is
not a loop over the graphs.
You can go further:
http://jena.apache.org/documentation/tdb/dynamic_datasets.html
SELECT *
FROM <http://example/g1>
FROM <http://example/g2>
WHERE { .. }
is a default graph of just the union of <g1> and <g2> That is a loop
over the graphs. Imagine two graph out of 100K
It could be done with the quad filter hook:
http://jena.apache.org/documentation/tdb/quadfilter.html
but that is a low level hook and harder developer work to use.
Andy
-----Original Message----- From: Andy Seaborne
[mailto:[email protected]] Sent: Monday, June 03, 2013 4:26 PM To:
[email protected] Subject: Re: Ontologies and model data
On 03/06/13 18:09, Joshua TAYLOR wrote:
On Mon, Jun 3, 2013 at 12:41 PM, Cindy A McMullen
<[email protected]> wrote:
I've been working with Protege, where the 'individuals' are
loaded into the same model as my ontologies. In the real world,
however, I wonder whether one loads the ontologies into a
separate model from the actual graph data. Any best practices
here?
I typically create my data (mostly individuals and property
assertions) in an OWL ontology that owl:imports the ontology that
defines the vocabulary (mostly classes and properties) is defined.
I think that's fairly common practice, especially when referencing
ontologies that you didn't create.
If the individuals are in one named graph of a TDB dataset, the
ontology can go in another, so they are in different graphs. You can
query the combination with the union of named graphs as the default
graph of the SPARQL query.
Or you can use a union graph of two graphs in-memory (or indeed any
storage mixture).
Andy
