Re: [SE] Ontology Driven Architectures

Phil,

Sorry to disappoint you but there's no debate here, I agree with the 
objectives of the task force and your responses below.  I am just pointing 
you at places that have looked at this problem before, so you can both 
avoid the mistakes and build on the successes. 

I can put you in touch with the right people in the ASE community if you 
like.  *They* may take up the debate.

Cheers,
Chris

Phil Tetlow <philip.tetlow@uk.ibm.com> wrote on 01/05/2005 10:21:34 AM:

> 
> 
> 
> 
> Chris,
> 
> Many thanks and Happy New Year. Your point about  Automated SOftware
> Engineering (ASE) is obviously very relevant, but unfortunately this 
area
> is somewhat distant from my core technical background, as you know.
> Nevertheless Ive come across this line of thought before and, although 
my
> lack of knowledge constantly frustrates the hell out of me, I still find 
it
> unusual that no significantly convergent ideas have hit mainstream
> commercial take-up yet. I also appreciate that this has been tried and
> failed before - such is the way of the world, although it is a point 
that
> absolutely needs making.
> 
> I consider your comments on the 'excess baggage' that the inclusion of
> ontologies can bring in the design process to be an absolute truism, but
> this is a central problem with all metadata and even some forms of
> application data, no matter how new fangled or relevant! I don't 
consider,
> however, that ontologies need be treated as independent artifacts this 
time
> around. New methods of combining XML derivatives can easily be 
established
> so that underlying ontologies can 'intertwine' with semi-formal 
schematic
> design descriptions in the form of formal in-line annotation as Timbl 
has
> hinted on a number of previous occasions. If and when appropriate 
tooling
> (perhaps Rational etc) appears that can easily manipulate this type of
> artifact properly within relevant contexts, then I am confident that
> significant sections of the industry might be persuaded. As such, I
> personally hold the view that the climate may well be changing and it 
is,
> at the very least, our responsibility to highlight the potential gains 
of
> amalgamating Semantic Web technologies with more traditional design
> methods. For some, this may well prove a huge bonus, for others a real
> bind. That's the nature of our profession. We should be able to pick and
> choose from all the tools and technologies at our disposal. The real 
trick
> is combining them in ways that add unexpected quality and value...
> 
> Perhaps you could provide more input on a suitable candidate description
> for ODA, filling in the ASE point of view?.
> 
> Please forgive my ranting. I'm delighted to see some active debate 
emerging
> on this subject..
> 
> Regards
> 
> Phil Tetlow
> Senior Consultant
> IBM Business Consulting Services
> Mobile. (+44) 7740 923328
> 
> 
>  
>              Christopher Welty  
>              <welty@us.ibm.com  
>              > To 
>                                        Phil Tetlow/UK/IBM@IBMGB  
>              05/01/2005 09:07 cc 
>                                        Cliff Jones  
>                                        <cliff.jones@ncl.ac.uk>, Grady  
>                                        Booch <gbooch@us.ibm.com>, SWBPD  
 
>                                        <public-swbp-wg@w3.org>,  
>                                        public-swbp-wg-request@w3.org  
> Subject 
>                                        Re: [SE] Ontology Driven  
>                                        Architectures  
>  
>  
>  
>  
>  
>  
> 
> 
> 
> 
> 
> public-swbp-wg-request@w3.org wrote on 01/05/2005 08:29:12 AM:
> > Ontology Driven Architectures
> >
> > In all well-established engineering disciplines, modelling reality
> through
> > a variety of formal and semi-formal notations has proven itself 
essential
> > to advancing the practice in each such domain. As such, large section 
of
> 
> s/section/sections/
> 
> > the Software Engineering profession have evolved from the concept of
> > constructing models of one form or another as a means to develop,
> > communicate and verify abstract designs in accordance with original
> > requirements. Such ideas have spawned the fields of Computers Aided
> 
> Usually when you start with "x has evolved from y" there is a "to z", I
> read this and found myself expecting this sentence to finish.  So I'm 
not
> sure what you're trying to convey here.
> 
> Also, the research community of Automated SOftware Engineering (ASE),
> formerly Knowledge-Based Software Engineering (KBSE), has been around 
for
> about 20 years, and grew out of the remnants of the Automatic 
Programming
> community.  This community has been doing research in precisely this 
area
> for that entire time.  Check out the ASE conference at
> [http://ase.cs.uni-essen.de/]
> 
> > Software Engineering (CASE) and, more recently, Model Driven
> Architectures
> > (MDA), where models are not only used for design purposes, but 
associated
> > tools and techniques can be utilised further to generate executable
> > artefacts for use later in the Software Lifecycle. Nevertheless there 
has
> > always been a frustrating paradox present with tooling use in Software
> > Engineering that has arisen from the range of modelling techniques
> > available and the spectrum of systems requiring design: Engineering
> > nontrivial systems demands rigour and unambiguous statement of 
concept,
> yet
> > the more formal the modelling approach chosen, the more abstract the
> tools
> > needed, often making methods difficult to implement, limiting the 
freedom
> > of expression available to the engineer and proving a barrier to
> > communication amongst lesser experienced practitioners. For these 
reasons
> 
> s/lesser/less/
> 
> In US English, at least, the "lesser" in  "lesser experienced
> practitioners" modifies "practitioners" not "experienced"
> 
> > less formal approaches have seen mainstream commercial acceptance in
> recent
> > years, with the Unified Modelling Language (UML) currently being the 
most
> > favoured amongst professionals.
> >
> > Even so, approaches like the UML are by no means perfect. Although 
they
> are
> > capable of capturing highly complex conceptualisations, current 
versions
> > are far from semantically rich. Furthermore they can be notoriously
> > unambiguous. A standard isolated schematic from such a language, no
> matter
> 
> Surely you mean ambiguous?
> 
> > how perfect, can still be open to gross misinterpretation by engineers
> who
> > are not overly familiar with its source problem space. It is true that
> > supporting annotation and documentation can help alleviate such 
problems,
> > but traditionally this has still involved a separate, literal, verbose
> and
> > long-winded activity often disjointed for the production of the actual
> > schematic itself.
> >
> > What is needed instead is a way to incorporate unambiguous, rich
> semantics
> > into the various semi-formal schemes underlying methods like the UML. 
In
> so
> > doing, the ontologies inherent to a system?s real world problem space 
and
> > its various abstract solution spaces could be encapsulated via the 
very
> > same representations used to engineer its design. This would not only
> > provide a basis for improved communication, conformance verification 
and
> > automated generation of run time-artefacts, but would also present
> > additional mechanisms for cross-checking the consistency of 
deliverables
> > throughout the design process and enable stronger inter-project
> > connectivity via the sharing of ontological concepts.
> >
> > In many respects an ontology can be considered as simply a formal 
model
> in
> > its own right. Hence, given the semantically rich, unambiguous 
qualities
> of
> > information embodiment via ontologies on the Semantic Web and the
> > universality of the Semantic Web?s XML heritage, there appears a
> compelling
> > argument to combine the semi-formal Model Driven techniques of 
Software
> > Engineering with those common to Ontology representation on the 
Semantic
> > Web.
> 
> You should know that this has been tried before and failed.  The problem
> was that the ontology, as an independent artifact, needed to be 
maintained
> to stay relevant, but after requirements, specification, and design were
> complete, the ontology was no longer strictly needed for maintenance of 
the
> software, and like documentation, fell out of synch with the software 
and
> became less useful.  It is extremely difficult to convince people that 
they
> need to maintain all these artifacts along with the software.
> 
> That's no reason not to try again, but understanding why previous 
efforts
> failed can't hurt as you go forward.
> 
> >
> > Kind Regards
> >
> > Phil Tetlow
> > Senior Consultant
> > IBM Business Consulting Services
> > Mobile. (+44) 7740 923328
> > ----- Forwarded by Phil Tetlow/UK/IBM on 05/01/2005 07:59 -----
> >
> 
> >              "Jeff Pan"
> 
> >              <pan@cs.man.ac.uk
> 
> >              >
> To
> >                                        Phil Tetlow/UK/IBM@IBMGB, 
"\"Grady
> 
> >              05/01/2005 07:29          Booch\"" <gbooch@us.ibm.com>
> 
> >
> cc
> >
> 
> >
> Subject
> >                                        Re: Ontology Driven 
Architectures
> -
> >                                        Help needed with an early
> 
> >                                        description for W3C please
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> 
> >
> >
> >
> >
> > Hi Phil and Grady,
> >
> > Sorry for getting back to you late - our servers had been down since
> > Christmas and they only went back to work earlier this morning.
> >
> > In accordance with Grady's suggestion, what do you think if we extend 
the
> > first sentence of the last paragraph into
> >
> > "In many respects an ontology can be considered as simply a *formal*
> model
> > in its
> > own right. "
> >
> > Happy New Year,
> > Jeff
> >
> > --
> > Dr. Jeff Z. Pan  ( http://DL-Web.man.ac.uk/ )
> > School of Computer Science, The University of Manchester
> >
> >
> >
> > ----- Original Message -----
> > From: "Grady Booch" <gbooch@us.ibm.com>
> > To: "Phil Tetlow" <philip.tetlow@uk.ibm.com>
> > Cc: "Jeff Pan" <pan@cs.man.ac.uk>
> > Sent: Sunday, January 02, 2005 5:50 PM
> > Subject: Re: Ontology Driven Architectures - Help needed with an early
> > description for W3C please
> >
> >
> > What would you think about prefixing your message with the sentence 
"In
> > all well-established engineering disciplines, modeling reality through 
a
> > variety of formal and semi-formal notations has proven itself 
essential
> to
> > advancing the practice in each such domain."
> >
> > The point here is that are troding ground that others have, and thus 
what
> > we are pursuing is relevant.
> >
> > Grady Booch
> > IBM Fellow
> >     Voice:    (303) 986-2405
> >     Mobile:  (303) 898-7091
> >     Fax:        (303) 987-2141
> >     Video:    (303) 795-6587/6626
> >     GPS:      39.620/-105.076
> >     Notes:    Grady Booch/Boulder/IBM
> >     E-mail:   gbooch@us.ibm.com
> >
> >
> >
> > Phil Tetlow/UK/IBM@IBMGB
> > 01/02/05 10:10 AM
> >
> > To
> > Grady Booch/Boulder/IBM@IBMUS, "Jeff Pan" <pan@cs.man.ac.uk>
> > cc
> >
> > Subject
> > Ontology Driven Architectures - Help needed with an early description 
for
> > W3C please
> >
> >
> >
> >
> >
> > Grady, Jeff
> >
> > You will be aware that one of the deliverables of the W3C's task force 
on
> > the Application of the Semantic Web in Software Engineering is a
> > publically available list of 'validated ideas and potential uses for 
the
> > Semantic Web in Software Engineering'. As such I have done some work 
over
> > Christmas to produce and initial description for the idea of Ontology
> > Driven Architectures (ODA). I must, however, confess that I have found
> > this task somewhat difficult and would hence really appreciate your
> > thoughts on my initial draft below, before I submit it to the general
> SWBP
> > mailing list for consideration.
> >
> > Ontology Driven Architectures
> >
> > Large section of the Software Engineering profession have evolved from
> the
> > concept of constructing models of one form or another as a means to
> > develop, communicate and verify abstract designs in accordance with
> > original requirements. Such ideas have spawned the fields of Computers
> > Aided Software Engineering (CASE) and, more recently, Model Driven
> > Architectures (MDA), where models are not only used for design 
purposes,
> > but associated tools and techniques can be utilised further to 
generate
> > executable artefacts for use later in the Software Lifecycle.
> Nevertheless
> > there has always been a frustrating paradox present with tooling use 
in
> > Software Engineering that has arisen from the range of modelling
> > techniques available and the spectrum of systems requiring design:
> > Engineering nontrivial systems demands rigour and unambiguous 
statement
> of
> > concept, yet the more formal the modelling approach chosen, the more
> > abstract the tools needed, often making methods difficult to 
implement,
> > limiting the freedom of expression available to the engineer and 
proving
> a
> > barrier to communication amongst lesser experienced practitioners. For
> > these reasons less formal approaches have seen mainstream commercial
> > acceptance in recent years, with the Unified Modelling Language (UML)
> > currently being the most favoured amongst professionals.
> >
> > Even so, approaches like the UML are by no means perfect. Although 
they
> > are capable of capturing highly complex conceptualisations, current
> > versions are far from semantically rich. Furthermore they can be
> > notoriously unambiguous. A standard isolated schematic from such a
> > language, no matter how perfect, can still be open to gross
> > misinterpretation by engineers who are not overly familiar with its
> source
> > problem space. It is true that supporting annotation and documentation
> can
> > help alleviate such problems, but traditionally this has still 
involved a
> > separate, literal, verbose and long-winded activity often disjointed 
for
> > the production of the actual schematic itself.
> >
> > What is needed instead is a way to incorporate unambiguous, rich
> semantics
> > into the various semi-formal schemes underlying methods like the UML. 
In
> > so doing, the ontologies inherent to a system?s real world problem 
space
> > and its various abstract solution spaces could be encapsulated via the
> > very same representations used to engineer its design. This would not
> only
> > provide a basis for improved communication, conformance verification 
and
> > automated generation of run time-artefacts, but would also present
> > additional mechanisms for cross-checking the consistency of 
deliverables
> > throughout the design process.
> >
> > In many respects an ontology can be considered as simply a model in 
its
> > own right. Hence, given the semantically rich, unambiguous qualities 
of
> > information embodiment via ontologies on the Semantic Web and the
> > universality of the Semantic Web?s XML heritage, there appears a
> > compelling argument to combine the semi-formal Model Driven techniques 
of
> > Software Engineering with those common to Ontology representation on 
the
> > Semantic Web.
> >
> >
> > Many thanks and Happy New Year
> >
> > Phil Tetlow
> > Senior Consultant
> > IBM Business Consulting Services
> > Mobile. (+44) 7740 923328
> >
> 
> 
> 
> Dr. Christopher A. Welty, Knowledge Structures Group
> IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532     USA
> 
> Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
> Email: welty@watson.ibm.com, Web:
> http://www.research.ibm.com/people/w/welty/


Dr. Christopher A. Welty, Knowledge Structures Group
IBM Watson Research Center, 19 Skyline Dr., Hawthorne, NY  10532     USA   
 
Voice: +1 914.784.7055,  IBM T/L: 863.7055, Fax: +1 914.784.7455
Email: welty@watson.ibm.com, Web: 
http://www.research.ibm.com/people/w/welty/