W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

Re: TAG issues during technical plenary

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Thu, 24 Jan 2002 16:27:36 +0200
To: Pat Hayes <phayes@ai.uwf.edu>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B875E678.C387%patrick.stickler@nokia.com>
On 2002-01-23 23:18, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:

> Why to a function? Wouldnt a URN be able to name almost anything?

My own view (which, like most views concerning this issue, is
controversial ;-) is that a URN denotes a digital resource that
(actually or potentially) is web-accessible.

IMO, a URN cannot denote abstract or non-digital entities (I'll
avoid calling them "resources" for the moment -- though I think
they are).

Thus, both URLs and URNs denote accessible resources. URLs denote
them directly -- specify their "location" -- and URNs denote
them indirectly, where their location may be context sensitive.

So no, IMO, a URN cannot name "almost anything".

> Let me add another thought. Some URIs may be best thought of as
> continuations, so that when invoked (called) they return a data
> entity but also (perhaps implicitly) another way to call the same
> function; and that next call may return a different data entity, of
> course. This lets the 'resource' (?) have some residual state which
> may change with time, rather than being a pure mathematical function,
> and therefore gives some flesh to the otherwise puzzling talk about
> 'conceptual mapping' in RFC2396.

OK, I think I see your point. Rather than a URN being a pointer
to a function it is simply a function that returns a function.


To dereference a URL is similar to executing a function
that returns as its value the resource,
whatever that may be.

To dereference a URN is similar to executing a function
that returns as its value a URL, which may
be dereferenced to obtain the resource, whatever
that may be.

URPs on the other hand, are non-dereferencable, and static
and thus are similar to constants. They do not compute to
anything else. They are just what they are.

Whether the dereferencing process/algorithm allows additional
internal redirections does not invalidate the above functional
single-execution-step interpretation, I think.

> Just a thought to keep y'all humming.

Humming, belching, growling, snarling, drooling... ;-)
> PS heres another thought. DAML is going through the throes of
> inventing a query language for itself. Is there any basic similarity
> between using a URI to access something, and posting a query and
> getting back an answer? Maybe a URI is a kind of generic atomic
> 'query' addressed to the web as a whole, along the lines of 'does
> anything with this name exist?'
> I have no idea if this makes any sense at all, but if it causes
> someone to have an epiphany, please remember me in your will.

Well...  just last week I jotted down some design notes for
a simple query portal that would take only a single URI and
return, in RDF of course, all of the knowledge known about
the resource denoted by that URI, with options for various
levels of verbosity, depth, and/or inference.

The context of this idea was a query portal at some major
standards site (W3C, IETF, ISO, etc.) for standards related
knowledge -- in this case, URI Class and Scheme taxonomies
in particular, but also with a view for standard vocabulary
terms, etc.

Thus, one could e.g. resolve "http://ietf.org/URIQuery?http:"
to get all knowledge known by the IETF about the 'http:' URI
scheme, etc. (taking the view that a colon terminated
URI prefix is a valid URI denoting the URI scheme itself).

Is this similar to what you had in mind?

(This is, depending on your perspective, a trivial generalization
 of the RDDL approach -- but for any URI (not just namespaces)
 and for all knowledge, in RDF (not just that defined by the
 RDDL vocabulary)



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Thursday, 24 January 2002 10:40:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:08 UTC