[redland-dev] Model aggregation
Dave Beckett
dave.beckett at bristol.ac.uk
Mon Mar 31 13:47:52 BST 2003
>>>Carlos Guerreiro said:
> > It was one of the few things that I added to the API before
> > implementing it - which I've avoided since as a bad idea.
>
> I suppose you mean it was a bad idea to add the API before implementing
> it?
Yes. Mea culpa.
> Well, what I have in mind is to integrate data from different sources by
> aggregating sub-models. Many data sources have a natural specialised
> representation but could also be exposed as RDF tuples, as sub-models of
> a broader aggregate model.
That's what the Redland design was meant to allow. The storage
implementations despite the name, can abstract the underlying
different sources in their representations. These can then be
accessed by models. Then the models can be layered (stores cannot).
But I just didn't get round to the latter. This is the kind of thing
that seems useful but I've tended to just make one big graph, in
aggregation but I understand totally when this can't work or isn't
feasible.
Time for ASCII art:
AggregatedModel
/ /\ \
/ / \ \
/ / \ \
/ / \ \
/ / \ \
/ / \ \
Model 1 Model 2 Model 3 OtherTypeofModel
| | | (no store)
| | |
| | |
Triple Store RDBS Store BDB Store
So some Models could have no store, others would provide either
triple stores or mappings from other types. OtherTypeofModel could
be an AggregratedModel.
So the plan was to use the model.add_submodel method to allow
construction of the above. The tricky thing was to implement all the
APIs, do the data merging and consider the update problem - where do
stored triples go in the aggregated model? The first sub-model that
can take them?
The Jena design (started at around the same time) has a similar set
of features.
Dave
More information about the redland-dev
mailing list