Hello Ivan,
Thanks for your detailed reply on issues in implementing the Statement
assertions.
On Jan 6, 2008 5:39 PM, Ivan Mikhailov <imikhai...@openlinksw.com> wrote:
>
> 1. Virtuoso uses quad store, not triple store so DESCRIBE implementation
> should find graphs that contain data about subject before producing
> actual result. For the sake of performance it will not even try to find
> absolutely all graphs that may be useful. If one graph contains
> Statements whereas other contains plain triples, should we stop search
> for graphs if only one of them is found? If we should stop, which graph
> should take priority?
I dont really understand this.
Are you saying that if one graph contains
:st a rdf:Statement; rdf:subject :foo; rdf:predicate :pred; rdf:object :obj .
and another graph contains the triple,
:foo :pred :obj .
then should the search stop if one of them is found ? I would say no
... because the graph containing triples may have addl triples as
well:
:foo :pred :obj; rdf:label "foo" .
Similiarly for graph with Statements ...
So, as you can see, i dont really understand that issue :/
>
> 2. It should be possible to configure whether rdf:Statements are
> expected in the database. This is important because some applications
> prefers to get DESCRIBE result that is a strict subset of the database
> in order to add only statements that are not stored already or to make a
> 'diff' between data that are really stored in different sources.
hmm agreed there,
> 3. Are rdf:Statements always stored in native-form quads or they may
> come from RDF Views?
>
> 4. May native-form quads contain rdf:Statements about subjects generated
> by RDF Views?
Sorry, I have not experimented with rdf views ...
> 5. Do all four triples of { ?ST a rdf:Statement ; rdf:subject ?s
> rdf:predicate ?p ; rdf:object ?o } always come from same graph or they
> can come from up to four separate graphs?
In my application, they would all appear in the same graph.
Personally, I dont see how a graph can be self consistent if for e.g.,
it contains only:
:st a rdf:Statement; :st rdf:subject :foo .
and expect other graphs to contain the predicate and object.
> 6. If there are only three triples, { ?ST rdf:subject ?s
> rdf:predicate ?p ; rdf:object ?o } but not { ?ST a rdf:Statement },
> the DESCRIBE routine "MUST"/ "MUST NOT" / "MAY" return { ?s ?p ?o } in
> the result set. Please suggest appropriate verb, 'RFC style'.
I would say, the triple assertion should happen iff :st isa
rdf:Statement (i.e., also subclasses of rdf:Statement).
Im sure experts will disagree with me about it, but my preference
would be for MUST NOT, in the absence of any rule in (future) ruleset
which asserts { ?ST rdf:subject ?s; rdf:predicate ?p ; rdf:object ?o }
=> { ?ST a rdf:Statement } ...
On a related note, does Virtuoso support some way (say predicate in
bif: namespace) to test/iterate-over container members ? I.e., I want
to do following:
:list rdf:first :blah; rdf:rest [ rdf:first :blah1; rdf:rest .... ] .
then,
select ?o where { :list bif:containerMember ?o .}
should return the following bindings:
:blah, :blah1, :blah2 ....
I think, list and more importantly tree support in an RDF database
would be a killer application. ie.,
select ?o where { :tree bif:treeNode ?o }
select ?o where { :tree bif:treeLeaf ?o }
and fitlers to restrict to particular tree levels ...
Anyway, I guess some/all of these things are already possible in
virtuoso ... i have yet to read all the docs.
Another problem I have is that for some reason the
HTML/JSON/Javascript result format returns bnodes with an id of
nodeID://<somenumber> but the RDF/XML result format returns in
:b<somenumber> for various queries... it would be great if it were
possible to somehow unify the two allowing me to issue further queries
in a recursive manner to retrieve the contents of the entire
list/tree. Its a very good thing that bnode ids are stable in
Virtuoso.
If I am in error in anything I wrote above, please do respond because
I'd like to learn more about it ...
Regards
Rajeev J Sebastian
