A Library of Taxonomies [was Brass Tacks #2]

[Kurt Cagle <cagle@olywa.net>]

> Okay, Brass Tacks #1 dealt with Applications masguerading as domains
> from Kurt Cagle's original "Reservations." I mentioned only one--the
> biggie, in my opinion. In my original bailout reply, I just said we
> had too many domains, and we do, as I alluded to by saying that any
> human endeavor was subject to a HumanML Application in some
> imaginable way shape or form.

It seems to me that we're already beginning to divide fairly clearly into
Application, Content, and Interchange roles, which I'd define along these
lines:

Taxonomic Content -- This covers the issues of defining the immediate
domains of interest and relevance for the structure itself -- the liberal
arts branch of this group with a focus on the needs of psychologists,
sociologists, and business people. I'd say Len is probably the dominant
person in this area, but only because I've not interacted with most everyone
else yet.

Interchange -- These issues basically involve defining the most concrete
structures, making it work effectively against other XML technologies and
insuring that we have multiple potential ways of describing the various
schemas in the appropriate venues. Sean Palmer is perhaps the most currently
active of the people handling the Interchange issues.

Application -- This is something of a multi-headed hydra, but esssentially
the applications people are the ones looking for ways to utilize the schema
for some specific task, whether it be 3D (and 2D) avatars and presence, user
interface development, personalization, community identity, and so forth.
These will be the consumers of the schema, and will consequently want to
shape it in their own interest, but realistically their concerns are domain
specific.

Most of the phase one are was really oriented around deciding where the
boundary between Application and Content should lie, something that I think
is still not fully resolved. It occurs to me that one exercise that may be
worthwhile for all of us individually would be to take the schema as it sits
right now and compare it with where our particular needs are, then compare
notes with one another (perhaps in Rex's Libraries). This may very well
expose holes in the schema, but I think it may also help to more clearly
delineate what we see as pressing needs for the schema vs. what would be
nice-to-haves that may in fact be more adequately handled by a modular
schema extension of some sort. Certainly the sense that I get right now is
that there are a lot of people who look upon HumanML as sufficiently
amorphous that it could solve their tasks, whereas I agree with Rex that we
need to start thinking of this from a more functional viewpoint.

The real danger with HumanML is that it could very quickly explode into a
structural domain of all human endeavors, which I think would be ultimately
futile.  On the other hand, I think if we do move back to the modular
approach that many of you agreed upon early on in this discussion at this
stage, then it will help us more adequately figure out ways of creating just
such a tree without ruining our day jobs in the process <grin/>.

One idea that I've had percolating for a little while is to actually move
away from the idea of creating a formal single schema, but rather towards
building a framework for taxonomy and a "Dewey Decimal System" for
integrating various taxonomies - a taxonomy of taxonomies if you will. Any
given domain of interest will have multiple schemas associated with that
domain for the purpose of describing different entities in that domain ...
the entities may be fairly similar, but not necessarily identical, and such
entities tend to arise spontaneously in response to need. We currently have
a kind of ad hoc indexing mechanism in the form of URNs, but those URNs are
organized largely around organizational needs rather than topical ones.

This raises some other major issues, admittedly, but it occurs to me that
such an effort would not only help make a HumanML system viable, but it is
also something that would have application to all groups within OASIS. You
could effectively reference a Business Process schema as something like
"urn://business/oasis-org/ebxml/process/2001/08/11/125A" while a schema for
describing ancient greek mythology might be something like
"urn://sociology/religion/ancient/hellenic/legends/2001/07/09/36B". This
would not only make modularization easier, but it also provides a way of
seeing in a comprehensive fashion what already exists.

I think it may be a good idea to see if somewhere along the line we can't
recruit a librarian...

-- Kurt Cagle