First, a few introductions:
VRML team, meet the URI group. The URI Working Group is the folks working
on standardizing the Uniform Resource Identifiers for the Net. URIs are
sort of the generalization of the more common concept of URLs; broadly
speaking, they are a collection of schemes for finding Stuff on the Net.
At this point, the major concepts have been drafted, and many of the
details filled in, although there's still a good deal to do there.
URI group, meet the VRML team. VRML is the Virtual Reality Modeling
Language, which is intended to become the basis for "cyberspace", a
language for modeling distributed 3-dimensional "worlds" on the Net.
The www-vrml mailing list is the list that discusses the language per
se, and is working on its evolution. (It's not an IETF working group
yet, although I suspect it'll become one sooner or later.) Version 1.0
of the language, a very rough first cut, is more-or-less final, and
we're starting to really discuss what needs to go into later
revisions. (Terminology note for the URI folks: a "world" is the
VRML equivalent to an HTML "page". Like a page, it may be composed
of a number of objects pulled in from elsewhere. This will become
important.)
I'm Justin; I've been one of the loudmouths on the VRML side pretty
much from the beginning, and have been lurking on the URI mailing list
for some months now. I *think* I understand most of the issues on both
sides, but people should correct me when I err or overgeneralize. (In
particular, I'm not sure that I've completely internalized all of the
issues surrounding URCs.)
This message has several purposes. The first is to simply make the two
groups a little more formally aware of each other. There's been
relatively little crossover (one or two people that I've noticed)
between the two that I've seen, and there probably needs to be a
little more. URIs are inevitably going to affect VRML, since VRML is a
Web-based (and therefore presumably URI-based) language; VRML is
probably going to affect URIs, because the language is rather
different from HTML, and has new needs that may require some new
twists to the notions underlying URIs. Best that we get to know each
other now, and start working together to understand how we can help
each other.
More specifically, I want to formally bring up an issue that's been
bouncing around the VRML mailing list for a number of months now in
a rather unfocussed way: how, in the long run, we want to store and
reference VRML objects. It's a broad issue, with a number of possible
answers. The solution we settle on may involve new forms of URIs,
tweaks to the VRML language, more intelligent browsers, or none or
all of these. But we've been buck-passing for months, and we need to
stop -- we really need to start hashing this out now, if we're to have
answers for VRML 2.0, sometime late this year or early next. (And I
think we need to address these questions if we are to pull VRML out
of just being a toy.)
Someone is inevitably going to say, "Oh, that's a browser issue" or
"Oh, that's orthogonal to our bailiwick." You may even be right. My
point is that, at this point, *we don't know*. We need to decide
whose problem this matter is, so they can work on it.
The issue goes something like this:
VRML is fairly bulky. Exactly how much code is required for good
worlds remains to be seen, but I think we can take it as an
assumption that a non-trivial VRML world involves a *lot* more
bits than a non-trivial HTML page. HTML pages *can* take a lot
of bandwidth (especially if you're shipping lots of pictures
around), but VRML ones almost certainly will.
VRML is also structured rather differently from HTML, and will
probably be used rather differently. By the nature of the problem, it
is considerably more object-oriented; worlds are made up of a lot of
discrete *things*. Moreover, these things tend to fall into classes
far more easily than HTML bits do, and will probably be far more
reusable.
Now, we all know that caching is a good thing, and one of the best
ways to deal with the bulkiness problem. But caching in HTML systems
pretty much always takes a relatively simple form, based on object
URLs. Even if the world moves over to using URNs instead, I expect
that the vast majority of cached "objects" will belong to exactly
one page.
VRML, on the other hand, suggests a very different mode of operation.
We *could* take a simple-minded approach, where everyone puts unique,
distinct objects in their worlds, and there is little overlap, as in
HTML. But it seems to make far more sense to build our cyberspace in
a way that makes sharing of objects straightforward and efficient.
Now, a number of people have objected to this, on the theory that if
we encourage sharing of objects, cyberspace will quickly develop a
deadening sameness -- everyone will use exactly the same objects, and
worlds will all look alike. I think this is *vastly* overstated. The
fact of the matter is that the real world repeats objects all over the
place. My telephone poles in Cambridge look pretty much like the ones
in Berkeley, I suspect. For the little details of the world like this,
sameness is the norm. There are towns that use funky custom poles;
similarly, there will be people in cyberspace who want to make
everything particular to their space. But most people just want a
telephone pole.
So here's the challenge -- what is the *right* way for us to share
objects? Long-term goals include browsers being able to recognize that
this telephone pole loaded from URL A is or can be used in URL B, and
hopefully being able to distribute a CD-ROM of the really common
objects, so they don't have to be loaded at all.
I can think of several different schemes off the top of my head.
Some examples:
Scheme A
--------
The simplest approach just uses URLs, and doesn't especially require
any changes. Some altruistic sites declare themselves to be standard
object repositories. People build worlds that refer to the objects
at these sites. Since everyone is using the same URLs, it is easy
for the browsers to detect the fact that multiple worlds are
referring to the same objects, and can utilize the cache sensibly.
Advantage: we can do it with today's proven technology.
Disadvantages: it isn't clear that anyone is all that altruistic. It
has the usual disadvantage of URLs: things move around. If we are
using standard objects heavily, a single site moving its stuff
around could have massive repercussions on the rest of the Net.
All the problems that led to the creation of URNs come into play
with great force. So...
Scheme B
--------
Same idea but use URNs instead or URLs.
(For the VRML folk: a Uniform Resource Name is the next level of
abstraction above URLs. It is a theoretically permanent name
attached to a specific object. The name includes a reference to
a name broker -- you can then go to the name broker to get the
corresponding URL. URI people, correct me if I've made any
mistakes here.)
Advantages: the usual strengths of URNs over URLs. This makes the
system relatively immune to location changes of objects, since it is
the name broker's problem to make sure that they stay up to date on
where things are. There are still some concerns (for example, if the
name broker goes out of business), but it's certainly an improvement.
Disadvantages: might still presume our altruistic object sites. (Can
this be made to work without them? Maybe, although we then need some
mechanism for publicizing common objects.) Moreover, it presumes that
the URN name-broker scheme takes off; this is still very new
technology, not being used by anybody yet. If no one wants to be a
name broker, we could be utterly screwed.
Scheme C
--------
My pet concept. Bear with me, this one's a little complicated. Those
of you who have been on the VRML mailing list for some time have
heard it (more or less) before.
Observation: like I said before, I suspect that most people aren't
going to care all that much about customizing the little details in
their worlds. Now I'll go further: I think that a lot of people aren't
going to care much about getting exact, specific objects for those
details.
I know, I'm committing a major heresy here. VR people tend to be
very impassioned that a world should be 100% reproducible -- when
you and I look at the same world, we should see exactly the same
thing. I think that, to some degree, this passion comes from the
fact that reprodicibility has clearly been one of the major goals
of VR for many years.
But I don't entirely buy it. Like it or not, we're not going to get
perfect reproduction. My system isn't as powerful as yours, so the
rendering engine leaves out details. My screen is lower-res, so those
little tiny things on the floor just wash out. And, frankly, people
don't even percieve the real world identically; I see no reason to
*insist* that cyberspace be any different.
Where am I going with this? Let's take another example. In the VRML
space I'm currently designing, I have a telephone in the foyer. A
telephone is a non-trivial object; a good one has lots of funny
curves, and it will take some time to download. But note this: I
genuinely don't give a rat's ass about exactly what that telephone
looks like. I really don't. Its only purpose in the scene is to
sit on top of the telephone books, which are the real pointers to
other URLs. The telephone itself is a detail I don't much care
about; if anything, I just want it to be something that the user
will recognize as a telephone, since its real purpose is to serve
as a mnemonic device.
This suggests a very different way of looking at objects. URLs and
URNs are both built for essentially the same purpose: to locate or
identify *one* specific object. URLs say where *a* specific thing
is. URNs say what *a* specific thing is. But what I really want here
is an instantiation of a class, whichever instance happens to be most
convenient for the user.
So, here's a simple solution: keyword classification. Conceptually, it
goes like this. An object can have any number of keywords associated
with it; these identify characteristics that the object has. They can
be at any level of specificity, as vague or specific as is needed.
When you put in a reference to an object, you can specify a set of
keywords that an object must match. These can, again, be as vague or
specific as you want. For example, in my example above, I could just
specify { "Telephone" }. If I had an office scene, and wanted an
appropriate phone, I could say { "Telephone", "Office" }, which might
get me a standard two-line phone with bells and whistles. If I care
about getting the right kind of phone, I could say { "Telephone",
"Rolm 300150" }. And if I really want *exactly* the right phone, the
one on my desk with my phone number on it, I could identify it as
something like { "Telephone", "Justin du Coeur's" }. (And add some
sort of unambiguous identifier if I'm just terrified that it might
still be ambiguous.)
Along with this list of keywords would be a default, which would be
a URL or URN. If the browser didn't have anything conveniently
available that matched the keywords, it would go fetch the object
using that. There are more details we could go into (like having
priorities attached to different keywords, so the browser can make
an intelligent guess about the best match), but they don't change
the essense of the idea.
There are a couple of different ways that this idea could be
implemented. When I first proposed it, my intention was that the
keywords and default would be separate fields in a VRML node; that is,
we would use a VRML-side solution. It was pointed out that this sort
of thing tends to be in the URIWG's bailiwick, so I began monitoring
that. My conclusion is that there isn't anything exactly right on the
drawing boards yet on the URI side; URCs are sort of in the right
direction, but there is no syntax (I believe) to specify a set of URC
fields to search on. I'm rather agnostic about which implementation
makes the most sense, but I still like the underlying idea.
Advantages: does *not* require any mythical altruistic sites; the
browser can classify objects as they get cached, on fields that have
no relation to the location the object came from. Doesn't require
URNs to have taken off. Allows *extremely* flexible classification
of objects, and permits users to be as vague or exact about which
objects they want as they like. I can throw together my house of
largely generic objects quickly, and the graphic designers can get
every little nuance just the way they want it.
Disadvantages: requires inventing a bit of new technology, albeit
a fairly easy one. Permits cyberspace to be ambiguous (which some
people feel is a drawback).
With this scheme, there are really two separate questions: 1) is
this keyword scheme a good idea?, and 2) if so, where does it get
implemented, in VRML or URIs?
There are probably other schemes possible; I've thrown out these
three because they're the three I've thought of to date. The
important thing is that we start discussing this matter, because
if we keep passing the buck around, cyberspace is going to remain
quite inefficient. And we need every bit of efficiency we can get.
So -- it's now thrown to the lions. Opinions?
-- Justin
VRML heretic-in-residence
Random Quote du Jour:
"There is an explanation for Attila. For Haman. For Cortez. For Cesare
Borgia. For Christie and Speck and Manson, and Nixon ... and Torquemada.
But only the Nemotropin know the explanation, and they smile as best they
can with bloody mandibles."
-- from "N is for Nemotropin"