Dear Ontolog Forum, (01)
In John Sowa's paper, Concept Mapping
http://www.jfsowa.com/talks/cmapping.pdf, he explains that most
customers do not know what they want until they see what they get. A
similar phenomenon happens with architectural design because many
customers cannot read plans. (02)
What is proposed herein is a first step towards what Pat Hayes called
"a kind of Building Code for ontologies" and "a very elaborate and
well-defined kind of planning". (03)
I believe each ontology should be built to reflect the information
running through it. More plain language, checklists, and simple
diagrams are needed for untrained customers that envision or need
idealized data transactions and interpretations to communicate their
needs and explain the information or knowledge they are caring for to
engineers. We the untrained do not know exactly which elements and
processes are essential in a "good" ontology. Its all too mysterious
and takes more special training and background knowledge than a
typical, for example museum director, can spend time learning
alongside their regular duties. (04)
With a checklist to follow, untrained customers will be better
prepared and able to state what their needs are and organize their
resources to provide ontology engineers, programmers, and formal
specification writers with what THEY need to get the data to flow in
potentially customized, atypical manners. (05)
Pat also stated previously "Im not at all sure however that we know
(yet) how best to plan a large ontology. For example, should there be
agreement first on an 'upper-level' ontology? This is often assumed to
be needed, and there are proponents of many rival UpperOntologies out
there, but Im quite unconvinced that such agreement is necessary or
even desirable, and that a much more useful approach is to focus first
on ways that different 'upper' frameworks (essentially, formalized
metaphysical positions) can be mapped into and from one another, and
then allow each 'lower' ontology writer to use their favorite. Others
will no doubt disagree: but my point here is to suggest that we simply
do not have a stable enough overall methodology yet, to justify the
adoption of an architectural-style planning/review process.". (06)
A helpful comparison to establish a baseline between the goals of
architects versus goals of engineers (in order to explain their design
to the brick makers who want to meet the requirements), is a document
produced by the American Institute of Architects (AIA) and Engineers
Joint Contract Documents Committee (EJDOC) is called "The Uniform
Location of Subject Matter". Essentially it is a 12 page table that
lists subject matters, for example Contract Time, to show which
documents contain which information and by chance, also show which
information typically needs to be covered for a contract to be
complete. (07)
Suggestions of similar work? The Concept Mapping paper also contained
an ISO draft for interoperable databases from 1978 that ended as a
technical report. Did this go anywhere since that time? What has been
done along these lines already to make such a document super down to
earth and, using our term, idiot proof? (08)
Debbie (09)
-- (010)
************************************************* (011)
Deborah MacPherson
www.accuracyandaesthetics.com
www.deborahmacpherson.com (012)
The content of this email may contain private
confidential information. Do not forward, copy,
share, or otherwise distribute without explicit
written permission from all correspondents. (013)
************************************************** (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: 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 Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (015)
|