The RDF Identification Problem

> On Friday, August 31, 2001, at 10:36  AM, Sandro Hawke wrote:
> 
> > RFC 2616 says that HTTP URIs denote "network
> > data objects or services" (not people).
> 
> Umm, no, I don't think it does. It says that:
>     The "http" scheme is used to locate network resources via the HTTP
>     protocol.
> 
> and that a network resource is:
>        A network data object or service that can be identified by 
> a URI[...]
> 
> But I don't think it ever says that these HTTP URIs denote these 
> network data objects, merely that they are used to locate them 
> (which sounds pretty reasonable to me).
> 
> I agree, it's somewhat annoying that the spec overloads the term 
> "resource" to mean network objects, as compared to what some 
> have called the capital-R Resources from the URI spec, but I do 
> believe that HTTP doesn't go as far as saying that all HTTP URIs 
> denote such lowercase-r resources.

I don't really know what you're trying to say here.   I think the word
"resource" generally clouds these issues more than it clarifies it.

It's tempting to argue this more, but my point is simply this:

  The example I quoted from M&S strongly suggests that one can and
  should use the web address of a person's web page as the logical
  constant (symbol) denoting that person in RDF statements.

This seems like poor practice to me, and it should not be recommended
by the spec.  The issue at least belongs on the RDF issues list.  (I
have also argued why this practice might be okay, in part 2 of[1].)


Whether the core WG can agree on a suitable replacement way to say the
same thing will be interesting.   I see three reasonable options:

  1.  Use existential variables.  The seems to be the leading practice
      among n3 users, who can easily identify "Amy" with
         [ foaf:homepage <http://mycollege.edu/students/Amy> ]

      I suspect there are some RDF users who are very uncomfortable
      with it.   It also can get tedious, and it's unclear what the
      performance penalties might be, compared to the other options.
      Otherwise, it's great.
     
  2.  Use URI fragments.  If we use something like
         http://mycollege.edu/students/AmyVocab#Amy
      and http://mycollege.edu/students/AmyVocab is not an HTML page,
      there is less confusion between the intended RDF denotation of
      the symbol and other possible denotions

      This has issues with RFC 2396 & mime-types, but it might work
      very well if one can fetch a definition (like the above n3) from
      the base URI.

  3.  Use URIs from some other scheme which does not restrict its
      domain of dentotation.   I'm not aware of any IANA-registered
      schemes with this freedom, which of course was why I proposed
      tanns/tags. 

      These should work well as global-scope existential variables
      (Skolem constants).   Something like:
          <tag:sandro@w3.org,2001-09-02:Amy> foaf:homepage 
                                 <http://mycollege.edu/students/Amy>.
      and then using <tag:sandro@w3.org,2001-09-02:Amy> as a symbol for
      Amy.    The approach works with (2) as well.

(1) has an advantage over (2) and (3) in guaranteeing the presence of
    a definition, and never having concerns about the definition
    changing.  An implementation technique of mapping that definition
    internally into a URI-like object might remove performance issues.

(2) has an advantage over (3) in network fetchability.

(3) has advantages over (2) in working for agents without web servers
    and avoiding possible other network dependencies.  It also avoid
    issues of confusion about the denotation of URI-References (which
    often look like web addresses to people).

There are a few other techniques, too, like the "tdb" scheme, or
publicly mapping (1)-style expressions into URIs.  I've written about
this all before, of course [1].  I just hashed it out again to see if
anything seemed to have changed.

    - sandro

[1] http://www.w3.org/2001/03/identification-problem/clever.html
[2] http://www.w3.org/2001/03/identification-problem

Received on Sunday, 2 September 2001 15:45:10 UTC