W3C home > Mailing lists > Public > www-rdf-interest@w3.org > August 2004

RE: Reification - whats best practice?

From: <Patrick.Stickler@nokia.com>
Date: Thu, 26 Aug 2004 11:18:59 +0300
Message-ID: <1E4A0AC134884349A21955574A90A7A50A1C22@trebe051.ntc.nokia.com>
To: <danbri@w3.org>, <sandro@w3.org>
Cc: <macgregor@isi.edu>, <leo@gnowsis.com>, <www-rdf-interest@w3.org>

If I'm understanding you right Dan, your approach seems to be
the same, in essence, as named graphs, where one makes statements
about the graph, which allows one to infer things about the 
statements within that graph.



Named graphs provide also for concepts such as "context" or "scope",
whereby a graph can be qualfied for or associated with a given
context, thereby allowing the context of its statements to be

Support for named graphs also results in a quad, but the fourth
element of the quad is the graph to which a statement belongs.

It's a far more generic, clean approach which has direct, albeit
somewhat implicit, support by the RDF MT -- since, after all,
it defines the nature of graphs, and graphs are clearly resources
which can be named by URIs, and all other use cases (contexts,
source/provenance, trust, security/acces, scope, etc) can be
defined in terms of named graphs, as application layers provided
for by particular vocabularies.

Anyway, just thought I'd toss that out there...  ;-)



> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of ext Dan Brickley
> Sent: 25 August, 2004 19:48
> To: Sandro Hawke
> Cc: Bob MacGregor; Leo Sauermann; 'RDF interesting groupe'
> Subject: Re: Reification - whats best practice?
> * Sandro Hawke <sandro@w3.org> [2004-08-25 12:37-0400]
> > 
> > 
> > > The right solution is to use contexts.  Contexts can be 
> implemented
> > > using quads instead of triples, or by using a scheme for
> > > encapsulating groups of statements, as is done in the 
> Triple system.
> > > The DAWG committee is taking baby steps towards contexts by
> > > including a SOURCE element in BRQL.  If you substitute the term
> > > "context" for "source" in a BRQL query, then you have quads.  Some
> > > of us are planning to "abuse" BRQL by treating the sources as if
> > > they are contexts.  I would not be surprised if members 
> of the DAWG
> > > committee have that in mind (but I can't speak for them).
> > > 
> > > At some point in the future, quad stores are likely to become
> > > commonplace--there are a few already.
> > 
> > While I'm fond of quad stores (eg in cwm and SWI prolog) and
> > agree they're generally the way to go -- how do you propose 
> exchanging
> > quad-store data?   My store knows that source x said {a b 
> c}, but how
> > do I publish that fact?
> This only covers a subset of usage scenarios, but works for me:
> In my published RDF files, I just assert things about the RDF/XML
> serialized document. Eg. that I'm its dc:creator or foaf:maker. I also
> like using a wot:assurance property to relate it to the output of the 
> PGP/GPG signing process.
> This is a bit of a hack, but in the noble tradition of adding 
> a layer of
> indirection to solve a problem. Instead of talking directly about
> triples or a graph, you talk about (using whatever RDF vocab you find
> appropriate) a document that has that stuff written in it.
> Rather than doc.rdf encoding "Sandro makes the claim that 
> 'the sky is falling 
> in'", have doc.rdf be "Sandro made skyisfallingin.rdf". Of 
> course context-tagging 
> tools are going to be useful in dealing with such data, but I think it
> avoids some of ugliness of RDF's regrettable reification vocabulary.
> Edd's FOAFBot showed that this approach was deployable (on top of a
> context-happy store, Redland). I suspect the existence of RDF
> reification has distracted people from simpler approaches like this.
> Also the other formalisms around RDF, notably the DL work, isn't happy
> with having to reason about claims like this. But then I don't use DLs
> so don't really care much there...
> Dan
> useful 
Received on Thursday, 26 August 2004 08:19:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:52 UTC