----- Original Message -----
From: Murray Altheim <altheim@eng.sun.com>
To: <ohs-dev@bootstrap.org>
> > You mean fragmenting data structures into too many namespaces?
>
> Well, a whole host of problems relating to what I feel is confusion
> over the role of markup, the supposed "attachment" of semantics to
> markup, the concepts of names, namespaces, addresses and identity,
> the separation between object and reification of object, etc.
>
> It's too bad we couldn't all go back to school for six months and
> take refresher courses in information theory, but unfortunately
> we'd deal with academics who would be in the same boat as us -- I
> think we're all too ahead of the curve sometimes for our own good.
>
> It'd be nice to see us figure out what we've got in front of us
> before jumping ahead into the next territory, but that's human
> nature I suppose. This coupled with the desire to be clever is
> leading us into morasse of complex markup that purports to solve
> problems few if any even understand. Not to pick on XML Schema
> (more than I've already) but I'm struck by a systems theory view
> that says that the process is overloaded with input. I think this
> is true of our industry right now.
Yep. But people don't want to do the grunt work, they just
want to start carving code.
Actually information/library science academics have quite a lot
to say -- many of them have worked in the trenches as reference
librarians. I see a lot of stuff published in "the knowledge space"
that obviously skipped over Library Science 101. A Bay area
company recently paid a knowledge management consultant
for six months to discover that a) users use different keywords
from those doing the cataloging, and b) catalogers, when in
the position of searching, will use different keywords from
when they are cataloging. This has been written up at UCLA
Info Science department, in 1968 I believe. Talk about not
doing your homework....
The tendency of docheads to consider data repositories
black boxes into which they "flatten" documents is not
helping matters either.
In ecommerce systems with under 100k objects I've tried
for a unified namespace several times, but never pulled it
off. There's always one set of data that makes the
information handling scheme go nutty, no matter how
I tweak the math. Normally I end up sweeping about
90% of the data into one space, leaving 3-4 database
fields as standalones. Of course if you're working
with a captive audience (employees), and you do
a good interface, data can stand quite a bit of
fragmentation.
N.
-- ________________________________ Nicholas Carroll ncarroll@hastingsresearch.com Travel: ncarroll@iname.com http://www.hastingsresearch.com ________________________________ >
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:05 PDT