Re: URIs-Resource relationships

On Thu, Sep 07, 2000 at 11:47:00AM -0400, liberte@crystaliz.com wrote:
> > 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.  

An emphatic "yep..."

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

100% aggreement there. The way I look at it is whether or not 
the characteristic your talking about applies to the identifier
or the class of things it identifies and not specific characteristics
of one of the thigns thats actually identified. I.e. the 'go' scheme
is a new URI scheme specifically because the thing it identifies is
a set of friendly names that can have local scope (ala the news scheme).
Those needed a new URI scheme because it was a characteristic of the
identifier itself and not a characteristic of the individual things 
being identified. But that's just my take on it... There are real
pragmatic reasons for not doing this as you points out.

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

Yep. That's the direction I had hoped we were going in...

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

Sounds resonable...

> 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 very useful thing to have!

> * 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"

Another good one...

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

Can you elaborate on this one WRT to references? I don't quiet follow...

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

IMHO, identifiers in the 'urn:' scheme do this but I'm not going
to begrudge someone else from doing it a different way...
See the OID URN namespace doc for an example...

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

Can you elaborate on this one as well?

> * Resources that are collections of other resources.
> 
> * Resources that "contain" other resources.
> 
> * Resources that will always have only one bit representation.

Which has a lot of applicability in the security realms...

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

But a solvable one....

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

Which is something that any URI scheme can do anyway...

> Whether an 
> application can trust that everyone is obeying the constraints is 
> yet another issue.

But at least the application can know that it isn't the one in error
if someone doesn't follow those constraints. Most of what we call
interoperability is really just being able to say that the other
guy is the one generating the error....

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

Yep. I think for some its the lack of knowing what the URI is actually
addressing, is it identifying the abstract concept or some specific
version of it or what. The URI can't tell you but that information is
very imporant to know before you can 'use' it.

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

There were some suggestions that these rules be written into 2396 and
that they apply to the general URI concept. I don't know if those
suggestions are still on the table or not...

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

Yep... The decision about whether or not your needs are best solved by
one or the other is a classic engineering decision...

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

I was speaking more in terms of what the most basic level of understanding
was. I.e. if someone's application doesn't use this URI<->Resource
relationship framework then they can still understand that a URI is
just an identifier and they can work within that simple framework.
My argument is more for keeping the URI base concepts as they are
and if someone needs something new at that level then they can create
a new scheme. If someone needs something and they don't mind using
the RDF based URI<->Resource relationship framework then they really
don't need a new scheme.

-MM


-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions	|          www.lp.org          |  michaelm@netsol.com

Received on Thursday, 7 September 2000 13:51:53 UTC