Re: The RDF Identification Problem

Brian - Since Sandro's note:

 [1] http://lists.w3.org/Archives/Public/www-rdf-comments/2001JulSep/0175.html

relates to:

 [2] http://www.w3.org/2000/03/rdf-tracking/#rdfms-resource-semantics

and:

 [3] http://www.w3.org/2000/03/rdf-tracking/#rdfms-editorial

would you please add [1] to the text of [2] and/or [3]?

Art
---

On Sun, Sep 02, 2001 at 03:44:42PM -0400, Sandro Hawke wrote:
> > 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

-- 
Arthur Barstow
W3C [MIT]
mailto:barstow@w3.org
http://www.w3.org/People/Barstow/
MIT: +1-617-253-7697

Received on Wednesday, 5 September 2001 09:15:49 UTC