Re: [dcat] rdf graphs and documents

\On 10-04-30 06:46, Chris Beer wrote:
> I seriously ( unless my RDF understanding is flawed ) would of assumed
> that you cannot by definition have a rdf:graph element. The graph has
> to be by nature dynamic, that is, it is, graph can only exist when
> subject, predicate, and object are known. It could act as a container
> for the 3 rdf elements, but in and of itself I see no point in
> defining it. I guess what I'm saying, by example, that there is no use
> in trying to define x in algebra, as x could be anything, or more
> importantly, x by itself could be anything. Or to put it another way -
> is there any point in defining a "page containing any combination of
> elements" within HTML - the concept of a page is the end result of
> markup, just as a graph is the end result of any rdf markup. (then
> again, prehaps it is worth defining graph as a rdf doctype or
> something). I'm no expert, so be gentle if I'm completely on the wrong
> track here :)

I think we're talking at cross purposes - probably my fault for
diverting the discussion a bit.

The meaning of graph is application-specific. That said, most back-ends
that I am familiar with (rdflib, 4store, redland) have the idea of a
graph or context as a container for triples - regardless of how they may
be returned from a web server. This allows, for example, SPARQL queries
of the form SELECT * WHERE { GRAPH <g> { ... }}.

I am concerned with versioned updates to these stores. The only
vocabulary for expressing changesets that I am aware of is the talis one
which makes use of reification, e.g.:

:foo a cs:ChangeSet;
    cs:addition [
        rdf:subject <bar>;
        rdf:predicate <baz>;
        rdf:object "hello"
    ] .

In this case, adding e.g. rdf:graph <g> in the addition is unambiguous
and meaningful. In fact it is necessary to communicate to the back-end
quadstore where it should put the triple.
Absence of rdf:graph means, to me, "put the triple in the default graph".

This is not to say that that anything in RDF requires this behaviour or
that implementations have a concept of graph or default graph that works
this way. But right now it is impossible to make a system like this
without an ad-hoc definition of a xyz:graph predicate and it feels like
such a predicate is close enough to the core that it should be defined
somewhere standard.

Cheers,
-w

-- 
William Waites           <william.waites@okfn.org>
Mob: +44 789 798 9965    Open Knowledge Foundation
Fax: +44 131 464 4948                Edinburgh, UK

Received on Friday, 30 April 2010 10:50:19 UTC