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

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

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 24 Jul 2001 11:26:32 +0100
Message-ID: <3B5D4D58.793BA677@hplb.hpl.hp.com>
To: pat hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org


pat hayes wrote:

> >
> >  o scope:  An application given a resource identified by a URI
> >    can reasonably expect to pass that URI to other applications and
> >    that they should be able to recognise it - c.f. my example
> >    on seeking references about a service offered in response to an ad.
> 
> I think this is wrong on several grounds. First, there is not in
> general any way to 'identify' the resource denoted by a URI. If I am
> given a URI then I may or may not be able to discover what resource
> it was intended to identify, but there is no general presumption that
> this can always be done.

Yes I agree that it can't always be done.  With an anonymous resource it
can never be done.  With a URI it can sometimes be done.  That is a 
difference and it may be significant to an application.


> Second, while of course the other
> application can recognise the URI in the sense that they know where
> it comes from, there is no general presumption that they can
> 'identify' what it denotes, ie discover exactly what resource that
> was supposed to be. In many cases this may be possible (eg it will be
> for URL's presumably), but not in general.

They may have some information about it, e.g. reference service.

> 
> >    If the response includes a reference to a service identified by
> >    a URI, the receiver could reasonably pass that URI to reference
> >    service to seek a credit/quality reference for that service.
> >    There is no point doing that for a variable.
> >
> >  o binding: An application given a resource identified by a URI
> >    can assume that URI denotes a specific resource - the
> >    binding decision has been made - an existentially quantified
> >    variable has not been bound to a specific resource.
> 
> I disagree. What do you mean by 'binding' here?

I mean that the mapping from the URI to the resource it identifies has
been defined.

> There doesnt seem to
> be any reasonable sense of binding for a URI.

see above.

> Certainly there isnt
> any way to bind a URI to the resource it denotes, in general (cf
> http://lists.w3.org/Archives/Public/www-archive/2001Jun/att-0021/00-pa
> rt#33
> "A resource may also be an object that is not directly accessible via
> the Web; e.g. a  printed book. ..... Anything can have a URI; the
> extensibility of URIs allows the introduction of identifiers for any
> entity imaginable."

We seem to have different notions of binding.

> 
> >  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.
> 
> In both cases, it is making assertions about some thing, ie some
> resource. The use of the URI may enable the receiver to connect the
> assertions made by the source to other assertions (perhaps made by
> other sources) about the same thing, made by using the same URI. That
> is the only sense in which a URI can be said to 'name' anything.
> 
> It isnt clear to me what the scope of anonymous node is intended to
> be, but it if it is the document containing the node, then indeed it
> should be impossible for any other source to say anything about the
> thing it refers to, so this is a genuine difference. However, the
> same is true of a non-anonymous URI if its use is restricted to this
> one source.

If I can tell that the scope of such a URI is so limited, then I think
I might be happy with that - so long as I can tell such URI's from those
those are not so limited.

Brian
Received on Tuesday, 24 July 2001 06:29:07 EDT

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