Re: lightweight reification (was Representing trust (and other contex t) in RDF)

At 11:23 AM 5/26/00 +0100, McBride, Brian wrote:
>At one level, the goal is to make be able to make statements about 
>statements, without invoking the perceived overhead of full RDF reification.

Yes.  And your use of 'perceived' is noted.  I agree.

>Since RDF statements can only be about about resources, then a resource is 
>needed that will act as a model for the statement.  The current RDF m&s 
>proposal is to create a resource, with 4 properties (type, subject, 
>predicate, object) and this seems to raise negative reactions.

Yup.  Most importantly, I believe this will be an impediment to real-world 
implementation, because of (a) the perceived overhead, and (b) it's not 
immediately obvious to a front-line developer why all this stuff is needed.

>My understanding of the digest proposal is to create a resource to model 
>the statement, but not add the 4 extra properties.  The problem is how to 
>relate that resource to the statement that it models.  It is  suggested to 
>relate the two by computing a digest of the statement and using that 
>digest to construct a URI for the resource that models the statement.

Yup.

>M&S is quite specific when it talks about reification that a statement and 
>the resource that models it are different things.  I haven't understood 
>why and I've just been wondering if one could consider statements to be 
>resources.

Guha has answered that more eloquently than I can.  (I love his example -- 
it may be the law, but that doesn't make it true, or even possible :-)

>One would then have models like this:
>
>
>        [this message] ---[was written by]--->Brian
>                                |
>                                |
>                            [asserted by]
>                                |
>                               \ /
>                              Brian

Indeed.  The trouble is, it doesn't fit the RDF model.  "[Was written by]" 
is an arc of the graph, and arcs can't be endpoints for arcs.  As an 
*implementation* technique, I think it's fine (in effect, treating each arc 
as a resource standing for the reification of the corresponding statement) 
and I am given to understand that this is just what many system 
implementations do.

But, being a protocol kind of person (sometimes), I am looking for how to 
*represent* this ("on the wire") to communicate the information to another 
party.

(Apologies for the laboured repetition here of my previous messages.)

>I think that this is effectively what the digest proposal does, but it 
>seems to me that the above is a simpler and cleaner model.  Thinking of it 
>this way, I don't think the digest is necessary and statements with 
>anonymous resources will work.

I agree it's effectively what the digest does:  it creates a 'handle' for a 
resource that can be used *within the current RDF model*.  But see above 
comments about the RDF model.

>However, the digest approach has the benefit that it can be represented by 
>the currently recommended syntax.

Atually, I think your approach can be represented reasonably within the 
current *syntax* (BagID, aboutEach, etc.);  it's just that in transferring 
to the RDF graph model you have to do a full reification (and then, it's 
not clear how to regenerate the original syntax from the model).  My 
problem is how to represent this stuff *simply* in the RDF graph model.

>The final thought I'd like to add is that when I think about implementing 
>the non-digest approach it seems it would be easy to provide 'full 
>reification' with very little, if any, extra work.  So I'm left wondering 
>whether the 'overhead' of reification is more perceived than real.

Two responses:

(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.)

(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.

Despite our apparent disagreements, I really think we are on the same path 
here.  Thanks for your comments.

#g


PS:  I am reminded that there is an alternative model for semantic graphs 
that might allow what you propose, that uses unlabelled arcs and two kinds 
of node for relations and concepts.  It's called "Conceptual Graphs", is 
attributed to 1984 work by John Sowa, and is briefly described in Luger and 
Stubblefield's book "Artificial Intelligence" section 8.3.


------------
Graham Klyne
(GK@ACM.ORG)

Received on Sunday, 28 May 2000 10:25:50 UTC