Eugene Eric Kim wrote:
> On Fri, 2 Nov 2001, Eric Armstrong wrote:
>
> > Basically, the answer to "how do we structure terabytes of
> information" is ... with meta-information that builds
> > a network of interrelationships
>
> I don't dispute this. My question is, who does the structuring, and
> how?
I really do see the rise of "ontology" as a profession. I see library
sciences transitioning into that role, joining a merge of web services
and technical support departments to deliver truly useful eFAQ systems.
Each company will start out as an ontological "island", but part of the
ontologists' role will be to build translation mechanisms for other
queries. Eventually, the existence of the translation mechanisms will
make it possible to search other islands for information, and begin to
build bridges. I continue to see the man-machine combination as the most
powerful ontology producer. Ontologists will have editing systems and
development environments. Tools will be built to automate some tasks,
but the majority of the effort will more of a writing process than a
factory-automation process. (Although there is reason to hope that Cyc's
"common sense" knowledge base will allow for a lot of automation that is
difficult to foresee.)
> Is it realistic to try to have hundreds, even thousands of people
> constructing topic maps from the terabytes of digital information that
> currently exists?
I think so. And I think it will happen. The ontologist/librarians who
are hired by the companies to make their solve-it and fix-it data
accessible to inquiries will give them the charter to do just that.
Businesses spend fortunes on this kind of stuff. In many ways, it's part
of the "organizational capital" of a serious enterprise. (Note: I
*don't* see John Q. Anybody doing this task.) The Nodal/Groves capacity
to "tack on" meta data to existing information will be pivotal in this
capacity.
Also, I see the process happening organically. I see the ontologist as a
supporting member of the technical support team, with the process going
something like this:
* customer asks question of eFAQ, gets useless response
* customer support rep gets into the picture, translates the problem,
and
finds information
* the top time-wasting queries are collected, and given to the
ontologist, along
with the question, "why can't we find this"
* ontologist maps existing data in ways that makes it accessible
* eFAQ developer tests the new mapping(s) while figuring out how to
make
the system respond to common queries in the most useful way.
> Keep in mind that the structuring has to happen as the
> information is created; otherwise, the information is always
> out-of-date.
That is truly ideal. "Real time" eFAQ generation would be awesome. But
in reality
there is always a time delay. Right now, the choice is between expensive
manpower
and useless FAQs. The focus in the new systems will be to minimize the
delay for human interpreters of the information and maximize the number
of satisfactory automated responses to common queries.
> In order for the Semantic Web to scale, you need to make implicit
> structure explicit automatically. There are a number of ways to do
> it. The science fiction scenario has intelligent agents reading
> documents and spitting out RDF metadata or Topic Maps.
That would be cool. I am impressed enough with Cyc to think that in the
15-20 year range it may well become possible. (Barring a comet, I am now
convinced that we *will* survive that long. The incredible response to
the energy crisis in California impressed me with the society's ability
to adapt quickly to problems. I even saw a PBS special on
energy-positive 3-story office buildings using solar power! And
California just passed a bill to start using solar power on government
buildings. Time to invest in those people!)
> On the opposite end of the spectrum, there are a number of more
> plausible scenarios. The example I throw out most often is e-mail.
> Quoting e-mail in responses produces implicit structure that could
> easily and automatically be made explicit with the right tools.
Yes. I think building a GUI tree-widget capable of displaying multiple
lines in each item is absolutely the key to the kingdom, on this front.
We have very few hierarchy-editors, solely due to the lack of that
widget. (There are dozens of attempts at XML editors, all of which have
different atrocious mechanisms to compensate for that lack.)
Give me a structured email tool in which I respond to your paragraphs by
position the curser and pressing Enter. It would look like the above,
only my comments would be indented under your paragraphs. Only my
comments would be transmitted in the reply, along with pointers to the
nodes they refer to. When you get it, the "review response" mode would
eliminate anything I haven't responded to. The paragraphs I *have*
responded to be flush left, with my replies indented underneath.
When you reply to my comments, they would be indented under mine.
Alternatively,
you could modify the original node, or add new nodes as part of the
original message.
When I get it back, the "review response" mode would show me things in
context --
your replies along with my comments, and your new and modified nodes.
Sure would love to see that happen. One difficult question to answer,
though, is
whether the hierarchical structure exists independently of type
information. In
other words, is "hierarchical structure" a special relationship in its
own right?
If it is a special relationship, then A1 is under A, and that's always
true, no matter
what. I might then categorize A as a proposition, and A1 as an
argument:for, but
the hierarchical relationship is unchanged by the categorization.
On the other hand, hierarchical structure might *derive* from
relationships. That
strikes me as more powerful, though perhaps less easy to implement, and
possibly
more confusing to use.
In that scenario, A1 is under A *because* it has been categorized as
Argument:For.
Without that category -- or some other structuring relationship -- there
is no way to
put A1 under A. That means that when write, you create A and B. Later,
when you
categorize B as Argument:For, it becomes A1.
Personally, I think there has to be a simple, constant notion of
"structure" that is
independent of categories, in order to have something you would call a
document. Otherwise, there really is nothing but "node soup", and all
document-views are
produced as the result of queries -- but that means having to set up
dozens of
relationships in order to produce something you want to think of as a
document.
Setting up lots of relationships to construct a "document" strikes me as
a lot
of extra work that no one will want to do. So I suspect that there must
exist
some form of hierachical structure that is "atomic". Other document
views may
well be constructed as a result of queries, but I don't think we can
entirely get
away from the concept of a more-or-less fixed "document".
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
This archive was generated by hypermail 2.0.0 : Wed Nov 07 2001 - 12:22:09 PST