RE: Clarifying what a URL identifies (Four Uses of a URL)

> That is a good summary, and solution.  Except for one small 
> thing. RDF uses IMHO the "identifies" function.

It's hard to know what "RF uses" by looking at the RDF
specification, which seems to disclaim responsibility for
defining how URIs in RDF are related to the concepts for
which they stand. So I'll interpret your IMHO to be that
RDF "should use" the "identifies" function.

I'd like to decompose this into three parts, if I may:

  (a) there is a single indicates(RDF) function.
      That is, there is only one context for all RDF uses.
  (b) indicates(RDF) (URI) =  indicatesRDF (identifies (URI))
      That is, the indicates function for RDF depends only
      on the resource identified, and no other aspects
      of the URI
  (c) indicatesRDF is the identity, i.e., the abstract
      concept indicated by a URI is the resource identified
      by the URI.

I think I can tolerate (a), except that it does seem that
different applications of RDF might already have chosen different
ways in which they use URIs to indicate concepts. I'm not
sure it's possible to close that barn door.

However, I have trouble with (b) and (c). One kind of
problem with (b) has to do with the handling of fragment
identifiers. The problem with (c) has to do with applications
wanting a broader range of things to be indicated than is
appropriate for the range of the 'identifies' function for
the 'http:' scheme. That is, if you really want to use
URIs in RDF to be able to identify abstract concepts, then
it's necessary to introduce some URI schemes that actually
can do the lifting for you (such as 'tdb'). If you really
want to use 'http:' URIs in RDF, then you need some other
way to lift from the resource to the concept for which it
stands.

------------------------------------
Fragment identifiers:

I think in order to account for fragment identifiers, I need
to expand the theory a bit, by expanding the domain of
'identifies' to include URI references with fragment identifiers,
and to expand the range to include 'fragments of representations'.
This is a little awkward, and so I'll introduce another
function, 'identifiesF'.

    identifies(URI) -> Resource
    identifiesF(URIRef) -> RepresentationFragment


If URIRef = root "#" fragID

   identifiesF(URIRef) == fragmentWithin(getRep(identifies(root)),
fragID)

   getRep(resource) gets a representation of the resource
   fragmentWithin(representation, fragID) identifies the fragment
            within the representation
   Note that
        fragmentWithin(representation, fragID)
   can be computed by invoking the function
        fragmentFinder(ContentType(representation)) 
   giving it the ContentEntity(representation) and the fragID.


This theory of fragment identifiers seems to work to describe
how fragment identifiers are used in browsers, but it doesn't
jive well with the use of fragment identifiers in RDF or in
namespace names.

I think the 'indicates' function is more uniform with respect
to URI references with and without fragment IDs, because no
actual representation, content type, or fragment finder is
necessary.

From the point of view of 'indicates', it's perfectly fine
to have an entity with a single node which has two different
IDs (foo and bar) and to use URI#foo and URI#bar to indicate
two different concepts, even though the fragment identified
is the same.
-----------------------
Range of 'identifies' vs. 'indicates'

I think my problem with asserting that the 'indicates'
function for RDF is exactly the 'identifies' function
is because I think it doesn't make too much sense to
have http URIs for 'the morning star' and 'the evening
star' (or 'Samuel Clemens' and 'Mark Twain'), even though
these concepts fit well into the range of 'indicates'.

------------------------
On choosing a theory for URI meaning:

In chosing an explanatory theory for URIs and their meanings,
it's useful to think about the criteria for "what makes a good
theory". Of course, it's useful for a theory to match current
common usage as well as it can (given that current usage is
sometimes inconsistent), but there are other properties of
a good theory. For example, I'd like some amount of stability:
that what a URI or URI reference indicates doesn't change
over time based on events that can't be discovered.

(Theories that are based on a URI reference indicating
"whatever the authority of the URI reference saying it means"
are unsatisfying in this respect.)

Larry
-- 
http://larry.masinter.net

Received on Friday, 24 January 2003 13:06:12 UTC