*bryan
|Guy and I have discussed this also. I think of this as de-normalizing the
|RDBMS schema for the reified triple store. Or perhaps re-normalizing it.
|In any case, it seems to me that this transform (of multiple rows of
reified
|triples / ARCs into a single row of a schema specific table) can only be a
|post-merge operation. Prior to merging, it seems that the data needs to
stay
|in the "normalized" form of the reified triple store model so that you can
|correctly recognize the various merging pre-conditions without undue
overhead
|and complexity. Also, once you transform the reified triples into the
schema
|specific table, you sort of lose the subject of the individual assertions
|that are being flatted into a single row of that schema specific table.
|I am curious if this matches with your experience. If so, then I can see
how
|this transform can provide very fast query mechansims whenever there is
some
|schema (and I am reading "schema" loosely here as some constraint on
patterns
|of reified triples, so association templates and RDF Schema would both
quality).
|However it will not help scaling for pre-merge operations.
|Unless you assume that all of your data is governed by some set of schemas
|that is known in advance?
I think that this is the key to building practical applications. Unless
the data is being controlled by some kind of structural constraints, you
are limited to processing the equivalent of "reified triples". By grinding
everything down to "amino acids" to use a biological metaphor, it seems
like it could be a lot of work to build everything back up to an
appropriate output structure "protein". In a relational database this is
usually something equivalent to numerous self-joins. The other option is to
use the equivalent of "schema specific tables and indexes" to cache higher
order structure. These structural commitments, however, limit your
flexability, and can be difficult to keep in synch.
I am also interested to hearing what practical experiences people have had
in dealing with this problem.
Guy
|
| 
