URL (OK, I know what that is. :)
URN
URC
URI
Thanks,
--Andy
[email protected]
At 01:37 PM 4/17/95 EDT, Mark Waks wrote:
>modest, at best.)
>
>Mark writes (at the end of his keynote thingy):
>>To construct a dictionary, we must be able to have a universal
>>name space for objects, both within an instance of a VRML
>>browser, but also, within the Web itself. It should not be necessary
>>to give the canonical telephone as a WWWInline with some
>>complex URL; rather, we should be able to say WWWInline
>>"telephone", and let the rest take care of itself. (This assumes that
>>the canonical telephone is being used.) There are proposals on the
>>table for a universal naming mechanism (the Universal Resource
>>Name) which spans the entire Web. Such a mechanism is an
>>essential part of this extension to VRML. If a likely URN
>>candidate does not exist by Midsummer, VRML designers will
>>either have to halt further development on scalable worlds, or will
>>have to use some other solution, such as ASN-1, to provide a
>>universal name space.
>
>Opinion: I'm not at all sure that, even when it's finished, URN's are
>going to be the *right* mechanism for this.
>
>To some degree, this may come down to a religious question: should
>pages always be 100% unambiguous? That is, should it be the case that
>two browsers will always wind up with exactly the same object set,
>given the same page? Or should we have a concept of "generic" objects?
>
>Mark gives the example of the "telephone", and assumes that we are
>talking about a standard, canonical telephone. I don't necessarily buy
>that assumption. I still say that there may be significant bandwidth
>advantages to allowing pages to simply build in "generic" objects,
>provided only if necessary. So, if a page specified just "telephone",
>and didn't specify anything more detailed than that, and your local
>site had a "telephone" object, your browser would just put that in,
>figuring that it was close enough. If you did *not* have a "telephone"
>locally, you could fetch it from the page's site.
>
>(My full proposal, which I made here some months back, is rather more
>detailed, and essentially allows WWWInline to define "keywords" which
>would be matched with the objects on-hand; the browser would decide
>based on that information whether the available objects were close
>enough to the desired object. It's out there in the archives somewhere;
>I can dig it out if there's significant interest. Suffice it to say, it's
>sort of like Level-of-Detail, but on a much more conceptual level.)
>
>Anyway, this is relevant because it's looking to me like URN's are
>going to wind up slanted strongly towards the unambiguous. That's not
>completely clear yet (the debates continue), but the general thinking
>*seems* to be that a URN should identify a more-or-less distinct object.
>
>Perhaps more importantly, all the URN schemes I've seen so far are
>intrinsically lookup schemes. The URN isn't a simple word like
>"telephone"; it's generally a path to a naming authority, which then
>provides you with a URL for the object in question. Doing local
>lookups (ie, given a URN, trying to find the named object on a local
>CD-ROM, without spending time on the naming authority) may well go
>against the spirit of URN's, I think. And it's looking quite clear to
>me that URN's aren't going to be a lot clearer than URL's are -- I'm
>really, really dubious that "telephone" is ever going to be a legal
>URN. Even if the URN standard hardens, and even if we decide that we
>need unambiguity, URN's still may not be great for our needs.
>
>URC's (Uniform Resource Characteristics) *might* actually have some
>promise for our purposes, but the discussion to date seems to have
>mostly focussed on very different needs from ours. We'd need to do
>some hard examination to decide if they will help.
>
>(Something to consider, for those who have their heads into the URI
>stuff: are our assumptions different from those that have come
>before? The HTML side of the Web, which formed most of the assumptions
>underlying URI's to date, has a subtle assumption that "standard"
>objects are rare. Most URL's have completely different "code" from
>each other, with little overlap. That indicates that the standards
>should assume that we always need to fetch things, since there is
>little common subsetting. But we are constructing an application
>where we expect *massive* subsetting, where most worlds will probably
>be largely constucted from similar objects, even the same objects.
>Does this imply different appropriate mechanisms? It might...)
>
>Anyway, we need to do some concrete thinking about these issues soon,
>and start talking about them. We may well want to get some cross-
>pollination between this list and the URI one, to try and make sure
>that the URI standards are adequate for our needs...
>
> -- Justin
> Who has been lurking on the URI mailing list
> for a couple of months now, trying to
> grok how it's going to apply to our
> needs...
>
>Random Quote du Jour:
>
>"On weekends, to let off steam, I participate in full-contact origami."
> -- Hugh Gallagher
>
>