W3C home > Mailing lists > Public > www-rdf-interest@w3.org > May 2000

RE: lightweight reification (was Representing trust (and other co ntex t) in RDF)

From: Graham Klyne <GK@dial.pipex.com>
Date: Mon, 29 May 2000 22:38:24 +0100
Message-Id: <>
To: "McBride, Brian" <bwm@hplb.hpl.hp.com>
Cc: RDF interest group <www-rdf-interest@w3.org>
At 12:47 PM 5/29/00 +0100, McBride, Brian wrote:

>I must appologise for the diagram not being clear.  The intent was to show
>the whole statement being the subject of the 'asserted by' property which
>would, I think, be consistent with the RDF model.

Ah, OK.  Consistent if the statement is reified.

>That seems simple and clear enough and not too hard to explain.  As you
>pointed out, there is a more compact representation using BagID and

But that compact representation does not extend to the model.  As I 
understand it, there is no 'aboutEach' node or property in the graph.

> >(1) as they teach on "management communication" courses and the like,
> >"perception is everything".  If poor perception stops developers from
> >adopting RDF in all its potential, then the damage is done.
> >(See Andrea
> >Chiodi's recent message to this list for an example of this effect.)
> >
>I'd agree with that.  I'm wondering whether a new mechanism is needed that
>is intrinsically easier to explain, or a way to explain reification in RDF
>which raises fewer objections.

Well, that would be a useful step.

> >(2) the perception becomes reality when one has to communicate
> >the reified
> >information between applications.  There are real costs of
> >bandwidth and
> >protocol processing complexity that get incurred here.
> >
>Yup.  Do you feel that the digest approach brings significant advantage?

Sergey pointed out that his similar approach reduces the RDF statement 
triple overhead from 400% to 100%.  Your mileage may vary:  this may not be 
an exact measure of the overhead but it seems a reasonable estimate.

I'd quite like to lose the 100%, but that may be hoping for too much.


Graham Klyne
Received on Tuesday, 30 May 2000 03:08:09 UTC

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