Re: Moratorium proposal

At 08:52 AM 7/8/00 -0400, Simon St.Laurent wrote:
>I'd like to propose that the W3C impose a moratorium on specifications
>using URIs and URI references for identification except in cases where
>retrieval is both expected and specified, and where the type of resource
>identified by the URI or URI reference is specified as well.

I cannot agree, since this would effectively stifle any developments based 
on RDF.

(To "expect and specify" retrieval for everything that is identified in an 
RDF graph would, I think, be unreasonable.)

>There isn't very much common understanding of URIs _as identifiers_,

Unfortunately, this seems to be the case (or maybe too much understanding, 
just not all in agreement?-).

>Specifications that want to use URIs as identifiers may do so by providing
>a formal description of the resource type to which the URIs apply, and
>identifying clearly how those resources are to be used/ignored/discarded by
>applications.

Are you talking here about _resources_ or _entitities_?

Where is the concept of "type" of a resource defined?

>Alternatively, the W3C could formally specify what URIs _mean_ in general,
>and how applications should deal with them when used in particular
>(semantic) contexts.  Saying "it's a resource" is not enough.

I would like to see a formal specification of "resource".  (I have my own 
working ideas, but am still not sure if they align with more widely held 
expectations).

>Yes, I understand that this may feel like a horrible set of constraints to
>a sizable group of people who like URIs in their present state.  On the
>other hand, it will go a long way toward making XML tools work as expected,
>by giving us only as much rope as we need to hang ourselves, and not
>everyone else on the Web as well.

As expected _by whom_?   Part of the debate here, I think, is that there 
exist different expectations about how things should work.  The current 
effort seems to be to minimize the extent to which those expectations are 
frustrated.

#g

------------
Graham Klyne
(GK@ACM.ORG)