Hi Ivan,
thanks again.
This must be one of the most informative mailing I've seen so far!
As before your answer is accurate, concise and helped me solve my problem!
Best regards,
Thomas
Ivan Mikhailov schrieb:
Hi Thomas,
I suppose the position of the G(raph) in the index pattern shouldn't
matter, since the graph part is not position bound, or does it make a
difference to create a SPGO or SGPO index, for example?
SPGO is better than SGPO when you know subject and you know predicate
and at the same time you don't know the graph, SGPO is better when you
know only S and G but not P. If you know all three then you may choose
from primary key GSPO, SPGO and SGPO -- the more selective fields are
leading the better.
Besides: in my application I only have one (i.e. the default) graph.
Is there a more optimal way to store this, e.g. a Triple structure,
while still making use of the existing functions, such as ttlp_mt(...)?
Anyway it's impossible to have triples instead of quads in a common
storage because system metadata are in system graph. If you really want
a triple store it's easy to create it using RDF Views, but it's not very
practical because RDF Views are not updateable in current version of
Virtuoso so you can create a triple store but can not fill it in with
data using existing API. On the other hand, compression will pack
repeating graph column into few bytes per page so it's not a noticeable
overhead.
Best Regards,
Ivan Mikhailov,
OpenLink Software.
