Hi Matthew, (01)
In concur with most of what you say below but want to emphasize the
point is to have the end user participate in the design process. Also,
to implement something similar to a design/build/commissioning process
so end users understand what they are procuring, contracting,
operating and maintaining as a system. (02)
I believe end users must participate in the analysis and
interpretation of what they actually need because they are the ones
who care about, understand, and create their information. It is not
all modular and interchangeable at their working level. (03)
Wholeheartedly agree with your position about lower levels picking and
choosing favorites. Ideally these particular favorites are gently
guided from levels above. Rather than favorites as if they were toys
or chocolates though - meeting the lower levels specifications. Design
specs which would be different than the absolute nitty gritty that
formal specifications seem to be for ontologies. At least as I
understand it. (04)
I will look at Epistle and thanks. (05)
On 2/23/07, matthew.west@xxxxxxxxx <matthew.west@xxxxxxxxx> wrote:
> Dear Deborah,
> See below.
> Matthew West
> Reference Data Architecture and Standards Manager
> Shell International Petroleum Company Limited
> Shell Centre, London SE1 7NA, United Kingdom
> Tel: +44 20 7934 4490 Mobile: +44 7796 336538
> Email: matthew.west@xxxxxxxxx
> > Dear Ontolog Forum,
> > 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.
> MW: I agree.
> > 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".
> MW: I think this is a good idea, though I think there are methodologies
> around (essentially those for developing/implementing computer systems)
> that can be used/learnt from.
> > I believe each ontology should be built to reflect the information
> > running through it.
> MW: What does that mean? Essentially, ontologies capture some knowledge
> about the world. One possible use of ontologies is in database design,
> and then data runs through them. Is it that use that is what you mean?
> > 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.
> MW: Definitely true. How to expose an ontology to end users is an
> issue. In my view, the ontology should simply be buried in a system
> that does something useful for the user. With a good ontology the user
> will notice that adding capabilities to the system is easy, with a bad
> one, he will struggle to do what he needs to.
> > 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.
> MW: I disagree. My experience is that you need to take what the
> customer says they need, and perform analysis to determine what they
> really need.
> > 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.
> MW: As a developer of one of these (ISO 15926) I agree strongly with
> Pat on this.
> > 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.".
> > 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.
> MW: Sounds a bit like the data handover guide we developed for the
> Process Industry in EPISTLE.
> > 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?
> MW: I have not heard of this. But ISO 15926-2 is a data model with the
> same objectives of integrating and exchange of engineering data from
> different sources/systems.
> > Debbie
> > --
> > *************************************************
> > Deborah MacPherson
> > www.accuracyandaesthetics.com
> > www.deborahmacpherson.com
> > 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.
> > **************************************************
> > _________________________________________________________________
> > 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
> 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
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. (011)
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)