URIs-Resource relationships

> On Thu, Sep 07, 2000 at 08:10:37AM -0400, Simon St.Laurent wrote:
> > I'm suggesting that the URI community stop hiding behind 'a resource is
> > anything you can identify' and start talking about what resources are.
 
On Thu, Sep 07, 2000 at 08:31:32AM -0400, Michael Mealling wrote:
> Why? A lot of us in other application arenas are perfectly happy with that
> definition and would prefer to keep it that way. Anything more constraining
> starts to put unnecessary controls on what someone can do with a URI
> and thats something we very explicitly _don't_ want to do.

I agree that, at one level, we don't want to overconstrain what might be
done with URIs and resources.  Some applications are fine with
not specifying any more constraints than we already have (i.e. close to 
nothing).  I think everyone understands and agrees with that.

I think we also understand and agree that some applications need more
constraints.  But one question is whether those constraints might 
retroactively apply to all applications or only some.   I believe the 
answer should be only some, to avoid over constraining, and to be 
backward compatible with already deployed applications.  

If we agree on that, then the next question is how those constraints
can be imposed while not imposing on all applications.   I can think
of two perhaps opposite approaches, and there may be many more
hibreds between these extremes.

One way might be to use new URI schemes as Micheal suggests, such 
that any URI in the new scheme and/or any resource associated 
with it would follow certain rules more restrictive than the general 
case.  But getting support for new URI schemes in existing
already deployed applications is still a hard problem, so there is 
a strong disincentive for people to rely on this strategy.

Another way to impose constraints on URIs and resources is outside
of the current URI schemes, and outside of the current protocols for 
resolving the URIs.  A framework for specifying constraints over existing
URIs and resources and a notation for expressing those constraints
could be invented or adopted.  RDF is one example of such a 
framework for specifying constraints (or any other
relationships between resources), and the RDF syntax is one of
the possible notations (albeit a problematic notation).

But even RDF doesn't do well in expressing relationships between
URIs and resources.  And that seems to be one of the first things 
that needs to be addressed.   We did have some discussions at W3C on
exactly how to do that using RDF - it would mean inventing the terminology
for expressing these relationships, and treating the literal URIs as 
resources themselves so we can talk about *them* rather than always
only talk about what they refer to.

What we need is a way of specifying things such as the following:

* A specific set of URIs that all map to the same resource by some
  measure of equality. 

* A general set of URIs, or URI patterns, that may be assumed to
  map to the same resources.  e.g. "case doesn't matter for us"

* URIs that are mapped to resources local to the resolver rather than
  the provider of the URI reference. e.g. your local weather station.

* URIs that are mapped to no internet representation but still
  somehow identify an abstract resource.

* Resources that are associated with multiple entities, which may
  or may not have their own URIs.

* Resources that are collections of other resources.

* Resources that "contain" other resources.

* Resources that will always have only one bit representation.

* Many other constraints that are about URIs and resources at the
  level of how URIs relate to each other, how resources relate to
  each other, and how URIs relate to resources.   
  
At this level, we don't have to be very specific about what kind of 
resources these might be in terms of MIME types or content formats,
or what kind of protocols are used to resolve URIs - all
that is abstracted out.  To some extent this is a fuzzy boundary
so figuring out where to draw the line is a problem.

None of these specifications of constraints would apply to all URIs or 
all resources, although new URI schemes and resolution protocols might 
be defined to automatically impose some constraints.  Whether an 
application can trust that everyone is obeying the constraints is 
yet another issue.

> I'm well aware of the issues that some of the applications you care about
> have with the general case of URIs and I sympathize. I share your
> views that the case of the 'http' scheme being a 'generalized namespace' 
> is vastly distorted and in many cases dangerous (just my personal opinion)
> due to its perceived uses and lack of rigorousness about its language.

It would be nice to have a list of the problems with the http scheme
in terms of the URI-resource relationships.  This could be used to
help avoid the problems in future schemes, and work around the problems
while continuing to use the http scheme with the kind of specifications 
I suggested above.

> In that case my suggested solution to you is to not attempt to redefine
> the entire space of URIs to adhere to your needs. 

I'm not sure anyone was suggesting that.  It would certainly be a lost
cause in any case.

> Instead _design_ a new scheme that does. 

Designing a new scheme is one approach that has its own problems.
Specifying constraints outside of specific schemes is another approach
that can work with existing schemes as well as new schemes.

> That's why we kept the entire generalized concept
> of URIs 'airy'. Its so that you can come along and design a scheme that
> does exactly what you want without having to inherit a lot of semantics
> that are incompatible with your application. Then further specify 
> that the application only works with a certain subset of the URI space.

Actually, I think that relying *only* on the creation of new schemes to
impose new semantics would be a mistake.  For one thing, that would 
mean you could never specify semantic relationships between URI schemes.
For another, you would have to repeatedly abandon current schemes 
in favor of new schemes.  At some point we will want an extensible 
semantics that can be layered on top of current schemes.  So
why not invent that extensible semantics now rather than rely on new
schemes?

-- 
Daniel LaLiberte
liberte@crystaliz.com
liberte@holonexus.org

Received on Thursday, 7 September 2000 11:45:18 UTC