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

Re: Subclass of Thing/Resource

From: Tim Berners-Lee <timbl@w3.org>
Date: Sat, 4 Mar 2000 11:14:33 -0500
Message-ID: <030401bf85f4$bab546e0$a60a1712@col.w3.org>
To: <guha@epinions-inc.com>
Cc: "Guha" <guha@epinions-inc.com>, "www-rdf-interest" <www-rdf-interest@w3.org>

-----Original Message-----
From: Guha <guha@epinions-inc.com>
To: Tim Berners-Lee <timbl@w3.org>
Cc: Guha <guha@epinions-inc.com>; www-rdf-interest <www-rdf-interest@w3.org>
Date: Friday, March 03, 2000 5:37 PM
Subject: Re: Subclass of Thing/Resource


>Tim,
>
> I think many of these questions center around
>precisely defining what an RDF Resource Identifier
>is supposed to be.


I thought that you could always identify and RDF Resource
by referring to that described by a given bit of XML.

>   I agree that we need to distinguish between RDF
>Resource identifiers and URIs.

That isn't what I said.  I would say that one can in universal
formal system put no constraints on Thing.

I don't think RDF Resources have idenifiers.
The way the Web works is, that

- RDF statements may refer to URIs
- URIs may ridentify documents
- documents may parse to RDF models
- RDF models are sets oif rDF statements

RDF identification using URIs wrks like this:

- RDF statemnts may refer to URIs with fragment IDs
- URIs with fragemnt idenifiers may refer to bits of XML
- Bits of XML may contain RDF descriptions of a given Thing.

On the web,  URIs are a primary way of identifying things. But you can of
course
use any unambiguous property fo something to identify it.

>A URI is a pretty formal object
>(protocol + host + opaque string) whose definition pretty
>concretely  constrains what can have a URI.

No, the HTTP spec defined a relationship between an abstract Document and an
identifier.
The SMTP spec defined the relationship between an sbtract Mailbox and an
uidentifier.
You could

> By
>this definition, people, places, etc. cannot have URIs.


We could extend URIs to these thinsg

ssn://usa/123-56-7897
latlong:N=54.68972;E=96.39723


but that ain't the point.  It is introducing all this as basic
infrastructure.
Now we have RDF we can identify someone indirectly. Suppose foo.rdf incldues

<rdf:description id="guha">
   <rdf:type resource="http://....dublicore#Person"/>
   <play:mailbox resource="mailto:guha@epoinions.com"/>
</rdf:description>

Now we can refer to your good self indirectly in two powerful ways. This
fragment effectively idenified you as that person who ahs mailbox
guha@epoinions.com.   Anyone else can now refer to you as that Thing which
is described by  foo.rdf#guha

This works just fine, and it is what the reference to the person type for
example means.  What I am saying is that while this works fine, I do also
need to refer to that element of XML. So we need a syntax to select which I
am talking about

<play:author  about1="#guha" resource="#tim">
<play:friend   about2="#guha" resource="#tim">

..meaning that I wrote the XML but I am a friend of the person.

This is exactly the parseType distinction in fact for embedded information.
I think there is an assymetry that the parseType allows you distinguish a
reference to XML from a reference to RDF for inline stuff but we need it to
linked stuff too. ..... (6)  (Issue for M&S)


> On the other hand, it would be very convenient to have
>a unique canonical identifier for refering to the one TimBL
>or one RalphSwick. In my reading, this is what the RDF
>Resource ID is. Everything (including literals, URIs, ...) could
>potentially have one of these.


Or many.  Something doesn't have to be unique to be unamiguous


>  I do think it would be nice if an application can assume
>some kind of structure to these identifiers, but not being
>able to do so would not be fatal.
>
> I agree with you that http://foo.org/bar.rdf#xyz is a lousy
>identifier for an object. To me, it just represents a position
>is a file.
>
> In the long run, the object identifier namespace will have
>to be like the DNS namespace.
>
> Reactions?
>
> guha
>
>
>
Received on Saturday, 4 March 2000 11:14:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:42 GMT