W3C home > Mailing lists > Public > public-swbp-wg@w3.org > January 2005

Re: [SE] Ontology Driven Architectures Second Draft etc

From: Phil Tetlow <philip.tetlow@uk.ibm.com>
Date: Thu, 13 Jan 2005 12:48:11 -0500
To: Daniel Oberle <oberle@aifb.uni-karlsruhe.de>
Cc: public-swbp-wg@w3.org
Message-ID: <OF6C5C10BA.A62E6EEC-ON80256F88.0061B78D-85256F88.007C7830@uk.ibm.com>


OK. Let me look at the text again and see if we can make individual points


Phil Tetlow
Senior Consultant
IBM Business Consulting Services
Mobile. (+44) 7740 923328

             Daniel Oberle                                                 
             karlsruhe.de>                                              To 
                                       Phil Tetlow/UK/IBM@IBMGB            
             13/01/2005 08:18                                           cc 
                                       Re: [SE] Ontology Driven            
                                       Architectures Second Draft etc      

Hi Phil,
when reading the text on http://www.w3.org/2001/sw/BestPractices/SE/

I was left a bit confused. What's unclear IMO is if

a) we want to use Semantic Web technologies in SE
    example: using OWL for reasoning and querying with software
    components in an Application Server to improve component-based
    SE (like done in [4]) -> the Semantic Web itself is of no interest here


b) we want to use/incorporate the Semantic Web in SE
    example: like you describe it in the text below, we could use the
    Web for runtime component sharing, not to mention the exciting
    possibilities of Semantic Web Services -> the Semantic Web with
    its annotated resources is of interest here

Apart from the fact that one can do both at a time, I think the
points should be presented separately. The distinction is also unclear
in the text below what gave me a hard time following it.
See my comments below:

> Ontology Driven Architectures
> In all well-established engineering disciplines, modelling a common
> understanding of domains through a variety of formal and semi-formal
> notations has proven itself essential to advancing the practice in each
> such line of work. This has led to large section of the Software
> Engineering profession evolving from the concept of constructing models
> one form or another as a means to develop, communicate and verify
> designs in accordance with original requirements. So spawning the fields
> Computers Aided Software Engineering (CASE) and, more recently, Model
> Driven Architectures (MDA). Here 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, arising from the range of modelling
> techniques available and the breadth of systems requiring design:
> Engineering nontrivial systems demands rigour and unambiguous statement
> 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
> barrier to communication amongst practitioners with lesser experience.
> 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
> capable of capturing highly complex conceptualisations, current versions
> are far from semantically rich. Furthermore they can be notoriously
> ambiguous. A standard isolated schematic from such a language, no matter
> how perfect, can still be open to gross misinterpretation by those who
> 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
> longwinded activity often disjointed for the production of the actual
> schematic itself.
> What is needed instead is a way to incorporate unambiguous, rich
> into the various semi-formal notations underlying methods like the UML.
> so doing, the ontologies inherent to a system’s problem space – real
In doing so ?

> or not - and its various abstract solution spaces could be encapsulated
> 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 and build process.
> In many respects an ontology can be considered as simply a formal model
> its own right. Hence, given the semantically rich, unambiguous qualities
> information embodiment on the Semantic Web, and the universality of the
> Semantic Web’s XML heritage, there appears a compelling argument to
> the semi-formal, model driven techniques of Software Engineering with
> approaches common to Information Engineering on the Semantic Web. This
> involve the implanting of ontologies directly into systems’ design
> schematics themselves, the referencing of separate metadata artefacts by
> such descriptions or a mixture of both. What is important is that
> mechanisms are made available to enable cross-referencing between design
> descriptions and related ontologies in a manner that can be easily
> engineered and maintained for the betterment of systems’ quality and
> Moreover, such mechanism should be capable of supporting both the

> interlinking of more broadly related ontologies into grander information
> corpuses – thereby implying formal similarities and potential
> between discreet systems through their design description metadata - and
> the transformation of designtime ontology-to-design-artefact
> into useful runtime bindings - thereby realising metadata use across a
> broader spectrum of the software lifecycle. This carries two obvious
> implications for Web-based systems employing such techniques; firstly
> the Web could be used as a framework for runtime component sharing
> discreet and disparate systems and, secondly, that new forms of hybrid
> system could be created through the amalgamation of discreet and
> functionality. This appears especially appealing given current advances
> areas of Web Services and Service Oriented Architectures. If underlying
> metadata were also used as a basis for parameterised dynamic systems’
> behaviour, there are further intriguing potentials in the areas of Web
> Service Choreography and autonomic systems.
Reading this paragraph one may conjecture that the only advantage of
ontologies in contrast to UML and the like are their precise semantics.
However, ontologies, as we know, are represented by languages with an
underlying logic that come with corresponding executable(!) calculi.
That gives us the exciting possibility to reason and query at runtime.
Contrast this with UML/MDA where you model but always need a compilation
step. Examples where reasoning and querying can help are again in [4].
You might have thought of all that in the sentences following "This would
not ..." but those advantages should be made more obvious.

> Composite Identification schemes on the Semantic Web
> Identity is one of the most fundamental ideas in conception. Without a
> notion of identity, it would become impossible to reuse information we
> previously acquired. Our experience would disintegrate into a sea of
> informational ‘moments’ with no global thread or coherence. In such a
> there would be very little we could usefully deduce. Studies of subjects
> with specific defects in the faculty of identity have shown just how
> significant a disability this can become. As with human cognition, it is
> common occurrence in the Semantic Web for us to need to be able to equate
> things based upon partial, observable data. Whilst the architecture of
> Web gives us a large, universal space of identifiers, we often need to
> with concepts for which there is no single globally-agreed identifier
> available. A notorious example, from the Friend Of AFriend (FOAF)
space missing Friend Of A Friend

> is that of a person. Most would recoil in horror at the idea of a single
> number identifying you worldwide, quite apart from the practical issues
> involved in running such a worldwide system of identifiers.
There is even a term coined `Semantic Web identity crisis' that results
from the ambiguous use of identifiers in Semantic Web ontology
languages such as RDF. In practice a URI can be used to reference a
on the Web, to reference (a fragment of) a document containing some
definition of a concept or to represent a concept (without any intended
reference to an actual location on the Web). Unfortunately, no standard
exists to distinguish between the three kinds of identifiers even
though they need to be resolved in different ways. Find more in [5]

> Inverse Functional Properties (IFPs) have come to the aid of those trying
> to model concepts without unique identifiers. An IFP is defined by the
> Reference as ‘[when] the object of a property statement uniquely
> the subject’. An IFP describes a relation to a piece of information that
> can uniquely identify the subject. It is important to note that an IFP
> not be functional from subject to object – in the FOAF ontology, a person
> can have many email addresses; the significant property is that each
> address corresponds to at most one person. A problem seen recently with
> IFPs is that there is a relatively small set of
> binary properties which can uniquely identify a subject. Many useful
> inverse functional relationships relate a subject and a piece of complex
> information. Many other useful inverse-functional properties only gain
> their uniqueness in highly specific contexts. The notion of Composite
> Inverse Functional Properties (CIFPs) aims to address these needs by
> allowing a composite references to act as an inverse functional property.
> Self-Organising Applications using Semantic Web Technologies
> Semantic Web Technologies in Highly Adapted/Adaptive (User) Interfaces
> Support Tools
> Links and Further Reading

Here is a revised and extended list:

[1] Philip Tetlow
     SOA, Glial and the Autonomic Semantic Web Machine – Tools for Handling
     IBM alphaWork Emerging Technologies


[2] R.V. Guha
     Object Co-identification on the Semantic Web.
     IBM Research,Almaden. *is this a publication or technical report?*

[3] Tom Croucher and Joe Geldart
     Situation and Identity – A Generalisation of Inverse Functional
     Currently under conference submission restriction

[4] Daniel Oberle, Andreas Eberhart, Steffen Staab, Raphael Volz
     Developing and Managing Software Components in an Ontology-based
Application Server
     In Hans-Arno Jacobsen, Middleware 2004, ACM/IFIP/USENIX 5th
International Middleware
     Conference, Toronto, Ontario, Canada, volume 3231 of LNCS, pp.
459-478. Springer, 2004.


[5] S. Pepper and S. Schwab. Curing the Web's Identity Crisis.
     Technical report, Ontopia, 2003.

[6] Holger Knublauch
     Ontology Driven Software Development in the Context of the Semantic
     Web: An Example Scenario with Protégé/OWL.
     1st International Workshop on the Model-Driven Semantic Web (MDSW2004)
     Enabling Knowledge Representation and MDA® Technologies to Work

[7] Daniel Oberle
     Semantic Management of Middleware
     In Proceedings of the 1st International Doctoral Symposium on
Middleware, Toronto, Ontario,
     Canada, pp. 299 - 303. ACM Press, October 2004.


[8] Daniel Oberle, Steffen Lamparter, Andreas Eberhart, Steffen Staab
     Semantic Management of Web Services.
     Submitted to WWW 2005, XML and Web Services Track

Received on Thursday, 13 January 2005 17:46:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:41 UTC