Dear Debbie (01)
>
>
> Hi Matthew,
>
> 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. (02)
MW: Of course, it just is not enough to "build what they say they want". (03)
> 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. (04)
MW: Sure. This is about applying standard engineering practices to
ontology development (I'm a Chemical Engineer by original trainging, so
I am quite familiar with what this means).
>
> 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. (05)
MW: Only to a degree. I would not ask the Refinery Manager to participate
in the specification of the gasket for joining two lengths of pipe, but I
would expect to involve him in how much the pipe was going to cost and
what it was going to connect, and what the benefits were. The same
principles apply to ontology engineering.
>
> 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. (06)
MW: I have a more pragmatic view. Good upper ontologies simply save you
the effort of doing the same stuff again and again. We recently developed
a corporate data model for Shell's Downstream business using ISO 15926
as a foundation. When presenting this to a conference I asked how much
members of the audience thought this should have cost. The man from BP
said $5m, the actual cost was $1m. This gap was largely attributable to
using ISO 15926 as foundation.
>
> I will look at Epistle and thanks.
>
> Debbie
>
>
>
> On 2/23/07, matthew.west@xxxxxxxxx <matthew.west@xxxxxxxxx> wrote:
> > Dear Deborah,
> >
> > See below.
> >
> >
> > Regards
> >
> > 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
> > http://www.shell.com
> > http://www.matthew-west.org.uk/
> >
> > > 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.
> >
> http://www.btinternet.com/~Chris.Angus/epistle/specifications/
> handover.html
> > >
> > > 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
> >
> >
>
>
> --
>
> *************************************************
>
> 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
>
>
> (07)
_________________________________________________________________
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 (08)
|