W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2001

Re: #rdfms-identity-anon-resources: provenance

From: pat hayes <phayes@ai.uwf.edu>
Date: Thu, 26 Jul 2001 13:36:07 -0700
Message-Id: <v04210106b7862af06490@[]>
To: Brian McBride <bwm@hplb.hpl.hp.com>, Graham Klyne <Graham.Klyne@Baltimore.com>
Cc: w3c-rdfcore-wg@w3.org
>At 11:18 AM 7/24/01 +0100, Brian McBride wrote:

This must have been one of the messages my mailer lost, so here is my 
belated response.

>>pat hayes wrote:
>> >
>> > >I was chatting with a colleague to day and the subject of anon resources
>> > >and provenance came up.
>> > >
>> > >Assume I recieve the following rdf from some source SOURCE, 
>>possibly with a
>> > >digital signature:
>> > >
>> > >  <rdf:Description>
>> > >    <foo:bar>foobar</foo:bar>
>> > >  </rdf:Description>
>> > >  <rdf:Description rdf:about="http://goo">
>> > >    <foo:bar><foobar</foo:bar>
>> > >  </rdf:Description>
>> > >
>> > >If were to represent this in my machine as:
>> > >
>> > >  <gensym:1234> <foo:bar> "foobar" .
>> > >  <http://goo>  <foo:bar> "foobar" .
>> > >
>> > >this is not the information that SOURCE signed - SOURCE made no assertion
>> > >about <gensym:1234>.  We'd have to be able to distinguish between the
>> > >gensym'd URI and the 'real' one.
>> >
>> > As I said a while ago,
>>I'm struggling slowly to understand.  My appologies if I miss the
>>significance of some remarks first time around.

Sorry, I meant only to provide the back reference, not to rap your knuckles.

>> > it matters who generates the gensym. If SOURCE
>> > uses an anonymous node (existential quantifier) then indeed you are
>> > not entitled to replace it with a gensym and say that it represents
>> > what SOURCE said.
>>The syntax clearly allows anonymous resources.  I think you have just
>>said that a parser, which on receiving RDF/XML containing anon
>>resources, assigned URI's to the anon resources when spitting out the
>>triples would not be representing exactly the information it had
>>as input.  Are we agreeing on this?

Yes.  It would not be representing EXACTLY the same information, 
since there is some information just in the use of the new name. You 
can imagine a conversation going like this:
A: There is a frog in my sandwich.
B. OK. Let's call it 'joe', OK?
A: OK.
Now, there is a small sense in which B has contributed 'information' 
to the discourse simply by giving the frog a name. But its a very 
small sense. Compare with
A: A frog I will call 'joe'is in my sandwich.
B: OK.

>>To represent exactly the information recieved, anon resources must
>>be a part of the model/abstract syntax.  Yes? No?

To represent *exactly*, yes. But see the section on skolemisation in 
the revised model theory I send out this morning.

>> > That is what the logic says also: the step from the
>> > existential to the skolem form is *not* a valid inference, so you
>> > would not be correct in saying that conclusion followed from what
>> > SOURCE said. However, SOURCE could have replaced his existential with
>> > a skolem constant
>>Could have, but didn't.  I suggest the requirement here is that
>>the abstract syntax/model be able to represent *exactly* the information
>>conveyed in the syntax.

OK, I agree. If the source sends you an existential, then you can 
skolemise it, but you should not claim that the skolemised form is a 
valid conclusion from what the source sent you. It isn't.

To illustrate why not, imagine sending it back to the source. If you 
sent back the original, the source could agree that is what it said 
to you; but if you send it back the skolemised form with the new 
name, then it has no way to know if the use of that name might not 
imply all kinds of content that it had not sent you. (If you 
skolemised 'honestly', of course, then it wouldn't, but the source 
has no way to check that.)

However, this really begs the question. If we have genuine 
existentials in  the langauge, then indeed we need to be able to 
distincguish them from uses of names. But the issue, seems to me, is 
whether or not to even have existentials in the language at all. We 
could interpret anaonymous nodes as having 'unknown' URIs, or URI's 
which are assigned arbitrarily in some non-conflicting way, ie 
'dont-care' URIs. Then there would be no real existentials in the 
language at all, so no need for the recipients to be able to make the 
distinction. And, the skolemisation point is, nobody who was making 
assertions would be any the worse off: they could still all say what 
they want to say just as well, but they would be using names to say 
it with.

>> > ( a newly generated URI, guaranteed different from
>> > any other URI anywhere else) and, my claim is, that you would have
>> > been told virtually the same content by SOURCE under those
>> > circumstances as you would have been by SOURCE telling you his
>> > existential. (Not quite *exactly* the same, since you would know, in
>> > addition to the fact that the thing exists, that SOURCE was using
>> > this URI to refer to it. But that information wouldnt help you make
>> > any inferences about the thing that you couldnt have made from the
>> > existential.) But indeed, if someone signs a document then it isnt,
>> > in general, correct to transfer that signature to another document
>> > that differs even in the slightest respect, so the issue of whether
>> > the inferences are valid or not may be irrelevant here.
>>My point here is that the abstract model should be able to represent
>>*exactly* the information that SOURCE intended to sign.  Any subsequent
>>inferences are the responsibility of the recipient.

I agree entirely. The issue is whether we allow people to sign 
documents that express existentials, or whether we insist that 
anything that is said, must be said using 'names' of some kind, so 
that if you want to talk about a frog (even just to say it exists) 
you have to give it a name. It doesn't cramp your style in any 
serious way, is the point.

Pat Hayes

(650)859 6569 w
(650)494 3973 h (until September)
Received on Thursday, 26 July 2001 16:35:58 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:50 UTC