David, Jack, Rich, and Ron, (01)
DE
> I thought the mundane issue of "legacy systems" was taken off
> the ontology table as irrelevant?
>
> Did I miss something? (02)
Just a few trillions of dollars worth of software that happens
to run the world economy. For some statistics and references,
see slides 4 to 7 of (03)
http://www.jfsowa.com/talks/iss.pdf (04)
JP
> Patrick Durusau and I tackled the "who gets to decide" issue in an
> Ontolog conference call in which we argued for a mapping approach
> that implies that virtually all choices are available, the final
> decision being left up to the user's particular needs. (05)
RC
> That is a great goal - preserving all the possible options
> for the final fitting of the ontology to the application. (06)
I agree with Jack, Patrick, and Rich. (07)
RC
> How do you document the options so that the final fitter understands
> the available choices? Given the open approach and its clear
> advantages over a one-size-fits-all ontology, a secondary issue is
> managing the spectrum of choices among multiple component ontologies. (08)
Yes, indeed. How do you organize, manage, and relate all options? (09)
JP
> Stretch that question to this one: how do you create a fabric of
> identifying methodologies that anyone can enter the loom and find
> what they want? which entails mappings among identifiers. (010)
Yes, but not just "among identifiers". The mappings must relate
things that are being identified. (011)
JP
> Topic mappers use the term "legend" just as you find in a corner box
> on a road map: a public declaration, essentially, of the keys used to
> identify topics. (012)
A topic map is a fine way to show the mappings, but as Barry Smith
noted, human mappings are error prone and fragile. We need some
systematic methods that derive the mappings from the structure
of whatever is being related. That is the point of the slides
I mentioned at the beginning of this thread: (013)
http://www.jfsowa.com/talks/par.pdf (014)
JP
> But, subject identification is more complex than that if you wish
> to include non-ontological commitments used by many, e.g. "Mary's
> husband" which relies on relationship traversal, "seeing as" (roles
> actors play), and more. (015)
The obvious solution to that problem is to include roles such
as Mary's husband in the ontology. Roles like employee, manager,
CEO, governor, president, buyer, seller, etc., must also be in
the ontology. (016)
Anything and everything that concerns human beings is expressible
in every natural language. It must also be expressible in any general
purpose ontology. That doesn't mean that every microtheory or special
purpose ontology must support everything, but the overall framework
must make room for every human thought, concern, and activity. (017)
JP
> I'd like to point out that topic mapping is never (by me or my
> friends) proposed as a substitute for ontology; rather, as an
> amplifier to the discipline. (018)
That's fine. I love methods for showing relationships graphically,
and topic maps have demonstrated the potential. But it's essential
to show all possible relationships and to derive them automatically
from two kinds of sources: formal notations and natural languages. (019)
JP
> The first and obvious (if only to me) solution is to craft a
> crowd-sourced topic map that, um, maps all known ontologies, thus
> providing a universal (careful there) index into ontologies. (020)
I like the idea of getting raw data from real people, but I don't
want to rely on only one source. Another important source is the
practice of billions of people over untold centuries, as documented
in the vocabularies and structures of our natural languages. (021)
Lexicographers have done an excellent job of documenting that
history in many well-edited dictionaries and terminologies.
I have always emphasized that *every* knowledge engineer should
have a good dictionary at hand. The definitions might not be
formalized, but they're usually far better than some random
guess that is scribbled down in some formal-looking notation. (022)
JP
>> (setting aside the simplistic notion that one URI satisfies
>> all users)? (023)
DE
> ... in 1980 I worked at a life insurance company renowned for
> it's data management efforts (this is NOT 'data management' in
> context of disks & storage).
>
> They had found 70 different labels/names for the core business
> concept "policy number." The one I still remember was M0101...
> an excellent Fortran name.
>
> Would that be an issue with the URI approach? (024)
There are huge numbers of issues with URIs. The most troublesome
is the assumption that the formal definition at the pointy end
of a URI has any correspondence with the meaning in the head
of the person who selected that URI by a menu click. (025)
RW
> In an earlier stage of life, I sold maintenance management systems.
> It quickly became clear that the functions required of the system
> had less to do with the industry that the company was in than the
> management style of the companies' leaders. (026)
Yes. That is one among many reasons why different people have
different meanings in their heads. And those meanings will
*always* take precedence over any formal definition on the WWW. (027)
Fundamental principle: The words and phrases that a person uses
in ordinary conversation are a far more reliable guide to that
person's meaning than any URI selected by a menu click. (028)
John (029)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (030)
|