Re: complete graphs

On Fri, Sep 30, 2011 at 1:43 PM, Mischa Tuffield <mischa.tuffield@garlik.com
> wrote:

>
> On 30 Sep 2011, at 13:31, Sandro Hawke wrote:
>
> The restriction on the fourth column is that the fourth column is the
> web address of a place (a g-box) currently serving that triple.
> (That's the architecture I'm arguing for in this morning's post to
> public-rdf-prov [1].)
>
> Personally I feel that this architectural decision will be what stops us
> from ending up in a world of quint-stores, sextuple-stores, and so on. A +1
> to Sandro's description of the 4th column being a web address of a place
> currently serving the given triple.
>
>
+1 to the sentiment of avoiding the stacking problem. I'm not sure that this
proposal does that though. How do I refer to the quads that state that a
triple was published at a web address yesterday?

I think graph literals are the sensible solution to the stacking problem
because they keep all the levels of provenence within the current triple
model. However graph literals do present usablity problems in terms of
querying the literals. SPARQL and other query languages could build in
support for accessing graph literals and I suspect it could be done without
any SPARQL syntax changes.

Imagine a hypothetical graph:

:foo :name "Ian" ; :stated :g1, g2, g3 .

:g1 a rdf:Graph ; rdf:graphContent "ex:bar1 a ex:Thing"^^rdf:turtle .
:g2 a rdf:Graph ; rdf:graphContent "ex:bar2 a ex:Thing"^^rdf:turtle .
:g3 a rdf:Graph ; rdf:graphContent "ex:bar3 a ex:Thing"^^rdf:turtle .

A SPARQL engine could parse the values of rdf:graphContent and make the
triples available for querying using the URIs :g1, :g2 and :g3 as graph
names.

Another advantage of graph literals is that they don't require new
serialisations to be created. Even RDF/XML would support them without
change.


Ian
-- 
Ian Davis, Chief Technology Officer, Talis Group Ltd.
http://www.talis.com/ | Registered in England and Wales as 5382297