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

Re: Action: #rdfms-identity-anon-resources questions

From: Graham Klyne <Graham.Klyne@Baltimore.com>
Date: Wed, 25 Jul 2001 09:57:11 -0400 (EDT)
Message-Id: <5.1.0.14.2.20010725130655.04694ca0@joy.songbird.com>
To: Brian McBride <bwm@hplb.hpl.hp.com>
Cc: RDF core WG <w3c-rdfcore-wg@w3.org>
At 11:31 PM 7/23/01 +0100, Brian McBride wrote:


>Graham Klyne wrote:
>
> > I think the assumption that the URI denotes a specific resource is somewhat
> > empty if one has no other knowledge about the resource thus denoted.  As
> > Pat pointed out, in this situation you can do no more than infer that such
> > a resource exists.
>
>If I use that resource twice, in one case I'd expect to use the same resource
>twice, in the other, I could not have that expectation.

(When you say "If I use that resource twice" I assume you mean "use that 
URI twice"?)

Indeed.  This is something that using a locally quantified variable name or 
a skolem-constant-like-name makes possible that is not possible using 
un-named resources.  In the XML syntax, several statements may be 
syntactically grouped to refer to the same un-named resource.  When 
translated to (say) N-triples that syntactic grouping is no longer 
available so some form of identifier must be provided.  Obvious stuff, maybe.

I think that, either way (i.e. using an existentially quantified variable 
or a skolem-constant-like identifier), generated identifiers from different 
documents (or unrelated parts of the same document) cannot be assumed to be 
the same resource though the possibility of them refering to the same thing 
cannot be excluded.  I.e. we don't know if they're the same or different by 
virtue of the form of labelling used.

> >
> > >   o provenance: when a source of rdf states some properties about
> > >     a resource named by a URI it is making assertions that the
> > >     resource named by that URI has those properties.  when a source
> > >     of rdf states properties about a variable, it is making no
> > >     assertions about the name of that resource.
> >
> > The detailed form of the argument here depends a bit on whether one assumes
> > that URIs:resources are 1:1, or if several URIs can identify the same
> > resource.  But either way I assert that two URIs can ultimately refer to
> > the same thing in the domain of interpretation.  Thus, assertions about a
> > resource named by a uniquely-generated URI MAY be referring to a resource
> > that is elsewhere known by a specified URI.  This seems to be the same as
> > information that one has about a resource identified by a variable.
>
>A sends signed rdf containing anon node to B.  It matters whether A or B
>generates the URI.  If B generates it, A has not signed that name->resource
>mapping.

Indeed, but what's in the name?  The signature provides some assurance 
about some entity that is denoted by a named used in the signed 
document.  The signature value itself depends on the name used, but the 
assurances conveyed do not.

I see three possible cases:

(a) Signature over a document containing a locally scoped variable

(b) Signature over a document containing a generated URI about which we are 
guaranteed to have no other information.

(c) Signature over a document containing an elsewhere-defined URI about 
which we may have some other information.

I think the assurance conveyed by the signature in cases (a) and (b) is 
indistinguishable.  In all cases, the name-to-some-resource binding *is* 
signed, but only in case (c) may we have any additional knowledge of the 
bound resource.

#g


------------------------------------------------------------
Graham Klyne                    Baltimore Technologies
Strategic Research              Content Security Group
<Graham.Klyne@Baltimore.com>    <http://www.mimesweeper.com>
                                 <http://www.baltimore.com>
------------------------------------------------------------
Received on Wednesday, 25 July 2001 11:23:53 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:38:17 EDT