Re: [SE] Ontology Driven Architectures





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/

Received on Wednesday, 5 January 2005 15:22:03 UTC