Re: theory and practice (Re: URIs for Physical Items)

Simon,

At 01:29 PM 10/27/00 -0400, Simon St.Laurent wrote:
>I'm not sure it's a solution that you'd be fond of, but there are two parts.
>
>1) Start publishing in plain English on why URIs are a good thing,
>      including examples that work.  Document the infrastructure(s)
>      surrounding URIs and differentiate between different types of
>      URIs and their 'proper' usage.  (To some extent, this means
>      documenting the understandings shared in the core community which
>      haven't been made explicit in documents like RFC 2396.)

It may not be perfect, but I found the following enormously helpful in 
coming to some level of understanding about the wider role of URIs...

   http://www.w3.org/DesignIssues/Axioms.html
   http://www.w3.org/DesignIssues/Fragment.html

and the following helps to show how the ideas can be applied to 
applications that are not necessarily the web-as-we-understand-it-today.

   http://www.w3.org/DesignIssues/Webize.html

As for infrastructure ...

>2) Consider an infrastructure for providing metadata and perhaps
>      'resolution' to an entity body which can be applied to all URIs,
>      regardless of schema.  In a strong sense, this is all about
>      metadata, and even the entity body can be considered a perverse
>      form of metadata for URIs.

... I think the problem is that any particular piece of infrastructure can 
apply only to some part of the uses to which URIs may be put.  (I'll 
suggest that even DDDS is not a universal solution for every imaginable URI.)

>While I value the chaotic approach, I haven't seen any attempt to balance
>that chaos with infrastructure (or even documentation) that developers can
>walk up to and figure out.  'itty bitty pieces' backed up with theory that
>doesn't play well outside of a core community doesn't seem like a recipe
>for success to me.

I think it is the role of _application_ designers to put together the 
pieces to create a complete specification that gives developers all the 
information they need to build an application.  It is in the nature of 
component pieces that they are not of themselves complete applications.

As for not playing well outside a core community ... yes, you have a 
point.  Personally, I think the main problem here is one of effective 
communication, but also to a lesser extent lack of absolute 
clarity/agreement _within_ the core community.  I predict that the next 
year or so will see a wider view of URI usage becoming more widely 
accepted.  The DDDS work may be one vehicle for this.

>Too many developers don't have control over the documents they have to
>process. In that situation, some kind of supporting infrastructure would be
>very helpful, and would remove a lot of the fear and loathing currently
>involved with URIs.

[Noting your later comment that you meant control over _URIs_]

For applications where this matters, it is important that the application 
specify or characterize the allowable URI schemes.  But such specification 
is not properly part of the specification of URIs.

But there are applications where this does not matter -- where URIs are 
being used simply as a way to label (identify) some resource (e.g. as you 
have argued the case for XML namespaces, or in RDF graphs of abstract 
knowledge).  In such cases, the URI scheme serves to identify rules of 
allocation/definition of URIs without necessarily saying anything about how 
such names are processed.

I would suggest that the power of URIs is that it allows applications to be 
defined using some specific form of names, yet leaves open a natural path 
for later extension to incorporate other, as yet unknown, kinds of 
identification.  I sense that your unease is with this open-ended and hence 
unspecifiable aspect of URI usage.

I grant that, in the final analysis, most applications must work with some 
specified set of URIs having properties appropriate to the task 
performed.  Interoperability specifications need to indicate the allowable 
set.  But the universal structure of URIs allows that new ideas can be 
incorporated into new versions of applications without breaking the core 
application architectures.

#g

------------------------------------------------------------
Graham Klyne                       Content Technologies Ltd.
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@mimesweeper.com>
------------------------------------------------------------

Received on Sunday, 29 October 2000 05:07:05 UTC