Why use URIs in RDF or KIF?

Let's see if I can dig out of this denotation-of-URIs mess from
another angle.  What could or might KIF [1] gain from using URIs where
it currently uses logical constant terms ("constants" in the spec)?
Alternatively, what does RDF gain by using URIs instead of ordinary
strings?

Let's see if I can answer this.

1.  Non-colliding strings.  Here we want two societies of agents, each
    with its own set of pre-defined constants to use to name things,
    to be able to share a common storage facility.  The danger is that
    the two societies might each define a predicate like "color", only
    one defines it like color(myCar, red) and the other like
    color(red, myCar).  So with URIs we end up with
    http://example.net/foo/color and http://example.net/bar/color, and
    we can tell them apart.

    Actually, more than being able to distinguish them, the URI-style
    names simply keep the two societies entirely apart.  The presence
    of data from society-2 in the data store used by society-1 will
    not (if things are working properly) be visible to society-1.

    But eventually agents can emerge which can participate in both
    societies, and by having the data in the same store (the web!)
    writing such agents becomes somewhat easier.

    If this is all you want from using URIs, then tag: URIs [2] are
    the way to go.  No messy retreival semantics, just a guarantee of
    non-colliding names.

2.  Documentation links.  It's kind of handy to use your browser to
    get documentation on the terms you're using or that you see being
    used.  So I can cut & paste http://example.com/foo/color into my
    browser and see that it takes a color as the second parameter.

    Of course, tag: URIs work fine here, too if I'm willing to use
    Google or some other directory service.  But if I want normal
    web-style lookups, I have to switch to having my constant names
    be something like HTTP URIs.

3.  Associated Information links.  It might also be handy to say
    any person or software agent can do a web retreival on the
    constant name and get some information which may be useful for
    something.   Conventions for what information is available
    and how you might use it can evolve over times.

4.  Formal Definition links.  As I've argued before [3], it could be
    very useful to say that each URI-used-as-a-constant is constrained
    by the content associated with it by the web.  That is,
    http://example.net/foo/color can only mean things that are
    logically consistent with what an HTTP GET on
    http://example.net/foo/color provides. 

I think it's kind of silly to use HTTP URIs unless one's going to go
at least to level 3 here.  Bringing us back to consideration of
denotations, I think level 4 makes pretty clear how we might
establishing sufficiently-shared interpretions of URIs.  

I'm curious at which level people think we should be trying to
operate... 

    -- sandro


[1] http://logic.stanford.edu/kif/dpans.html  (is there a better link?)
[2] http://www.taguri.org
[3] http://lists.w3.org/Archives/Public/www-rdf-comments/2002OctDec/0043

Received on Wednesday, 7 May 2003 07:31:52 UTC