Re: Moratorium proposal

At 01:30 PM 7/11/00 +0100, Graham Klyne wrote:
>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.

Not necessarily - it would simply require that the use of URIs in other
specifications be made far clearer, and that questions of retrieval and
comparison be addressed.

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

I can accept specifying non-retrieval as well, provided that _some_ rules
are provided.  RDF's own use of URIs would be grandfathered (and allowed to
continue development) by any sort of reasonable moratorium.

>>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?-).

I'd suggest that there is no widely shared understanding, though there are
communal understandings.

>>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_?

I'm talking about the conflation of resources and entities that happens
when you do things like put schemas at the entity body without making clear
how such expectations work.

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

It's not.  But I'd like to see distinctions made, whether in URIs or in the
specifications that use them, between 'retrievable' and 'non-retrievable'
URIs. Right now, a lot of people expect that 'http://' indicates
retrievable, when most of us on this list are aware that it doesn't.

In cases where the URI is to be used for retrieval, I'd like to see the
type of the entity body to be retrieved defined, along with rules for how
it fits into the process making use of the URI.

>>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).

I don't think the definition from RFC 2396 has gained anything from its
repeated quoting.  I would heartily support a revision that addressed more
aspects of URI usage and processing.

>>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.

As expected by people who see 'http://' and expect it to have its familiar
meaning.  As expected by people who want to compare A to B reliably.  As
expected by people trying to write generic namespace and XLink processors.

It's not clear to me that RFC2396 alone is a reasonable basis on which to
build other specifications and applications.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
http://www.simonstl.com - XML essays and books

Received on Tuesday, 11 July 2000 09:46:24 UTC