W3C home > Mailing lists > Public > www-rdf-logic@w3.org > May 2001

Desirata for Symbols (was Re: What do the ontologists want)

From: Sandro Hawke <sandro@w3.org>
Date: Sat, 19 May 2001 15:38:04 -0400
Message-Id: <200105191938.PAA09626@hawke.org>
To: "dehora" <bill@dehora.fsnet.co.uk>
cc: "pat hayes" <phayes@ai.uwf.edu>, www-rdf-logic@w3.org

>        . With my implementers hat, a resource is synonymous with a
> URI. In code I'm going to call my resource object a Resource, not,
> SomethingIdentifiedByAURIWhichMayOptionallyHaveAnchorIDs. So when I
> instruct a machine to hang a property value off a resource, I intend
> that this instruction will describe the resource not the URI that
> denotes it. Thus:
> urn:elvis urn:says urn:thankyuhveriimuj
> describes nothing about the URI urn:elvis, it's intended to describe
> whatever urn:elvis denotes: in this case, my neighbours lawn mower.
> This touches on the matter of social contract Dan Brickley mentioned.
> We agree that URIs identify things and we agree to call these things
> resources. If we didn't:
> urn:elvis, urn:says, urn:thankyuhveriimuj
> is not any more useful than saying either:
> "elvis", "says", "thankyuhveriimuj"
> In RDF, a resource is something identified by a URI (that may have
> anchor ids) as per rfc2396. That's all there is to it. I find it's
> useful way to think when it comes to implementing code.  That may
> seem a backways determination; if I create a URI do I create a
> resource for it to identify? This is moot, the RDF machine can't
> access a resource directly anyway, but it allows for the description
> of say, unicorns. 

What possible advantage does "urn:elvis" (or any other URI-like thing)
have over "elvis" as a logic symbol?

1.  We can prevent unintentional re-use.   This is like
    com.sun.SomeJavaClass or w3c_some_C_library_function.  Doing this
    allows us to skip a symbol translation stage in reasoning about
    two different expressions.

    I think there are cases, with agents communicating in a multi-path
    network, where the translation problem becomes impossible to solve
    without at least a mechanism for generating unique agent (or
    document) identifiers.  And if you need that generation mechanism
    for agents, you might as well make it available for all objects.

2.  There are some social mechanisms in place to designate who has
    authority to define the denotation of the symbol.  The clearest is
    probably urn:oid, which involves a whole mechanism in
    international law deligating denotational authority.  (I don't
    know how well it works, but I've heard it tries.)

    I have no idea how this actually helps, beyond the functionality
    in point #1.  Who cares if symbols starting urn:oid:1.2.840.113556
    may only legally be "defined" by Microsoft?  How do we use that

3.  Some URIs can point humans and/or machines to some definitional
    text, possibly even some permanent definitional text.  But is
    there an advantage to 
        "elvis according to the formal definition at http://example.com/elvis"
        (aka "http://example.com/elvis#elvis")
        "elvis234234"        [elvis with some uniqueness mechanism]
       with the nearby assertion
        ("elvis234234", formal_definition_website, "http://example.com/elvis")

    The later form gives us much more flexibilty to explore approaches
    to "definition", whatever that means.

4.  Some URIs already have a pretty widely known denotation.  Or do
    they?  What exactly does "http://www.yahoo.com" denote?  Is it a
    document, a service, a company, something you type into your
    browser, or what?  Heck, it's not even a decent URI -- it's
    supposed to have a "/" on the end.  You can quote RFCs 2396 and
    2616 at me, but if that meaning isnt exactly matched in the minds
    of some important group of people (and I would argue it is not
    yet), does it really matter?

My intuition here leads against the tide of the RDF community to
saying #1 is enough.    Anyone care to argue for 2, 3, 4, or something

    -- sandro
Received on Saturday, 19 May 2001 15:38:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:38 UTC