[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-ohs-talk] Fwd: Re: [PORT-L] Digital Imagination

> > Jack
> Perhaps it would help to clarify what is meant by "ontology". In my
> experience, this term is used to refer to two very different things:
> 1. A knowledge or data schema used by application developers to
> a common set of semantics among themselves. This ontology is intended to
> frozen, and "hard-coded" into the application, i.e., it is a way to spec.
> inter-operable software.
> 2. Information or knowledge deliberately factored out of the application
> code, so that it can be maintained by a different authority than the
> application developer(s), and updated independently. This is what is often
> meant by "thesaurus" or "taxonomy". While such factoring is often useful,
> not critical, it does limit the extent to which the application can
> compatibility: if the ontology can change, then it is not a stable
> "contract".
> If you make this distinction, then I think most issues can be productively
> re-cast as issues of which type of "ontology" a given bit of semantics
> should be incorporated into...    (01)

Words do have a way of changing when they are ported from English
to programming. Clarifying "ontology" certainly can't hurt, especially
since it is a philosophical term; in English definition, an ontology
attempts to define the fundamental essence of being, as it truly is.    (02)

This raises issues with both the first and second approaches. In the
first, if you hardcode in the fundamental essence of being -- as you
understand it -- then what if you turn out to be wrong? (This
happened to me in 1988, and I suspect others may have been
wrong once as well. But perhaps I am mistaken again.)    (03)

In the second, you abandon the notion of "one truth", at some cost
to interoperability, and for practical purposes abandon ontologies
in favor of thesauri and taxonomies. (While definitions on these
vary, they both change, albeit thesauri faster than taxonomies.)    (04)

Option one requires God, or someone able to do a good
imitation. There are many willing imitators, but the operative
word is *good*. Option two allows for human fallibility.
In the absence of God or a suitable stand-in, option two
is IMO the default.    (05)

And in the interests of interoperability, option two points to the
idea that data should be stored in the rawest, most granular
form possible. Because as accountants have known for 1,000
years, it's a lot easier to recast a column of figures than it is
to parse a lump sum.    (06)

Nicholas    (07)

Nicholas Carroll
Travel: ncarroll1000@yahoo.com
"The hardest single part of building a software system
is deciding precisely what to build." -- Frederick Brooks    (08)