Re: Fractal communities: Was: Rich semantics and expressiveness

Hi Danny,

By saying that for engineering disciplines the models/ontologies themselves 
are engineered I mean, for example, that the same sort of approaches to 
change management are taken for the ontology as for the products the 
engineers create. We've seen this as a big hole in the Semantic Web world 
where ontology evolution seems largely focused on merging ontologies or, even 
less usefully for us, on the automatic discovery of overlaps using structures 
and names (which in my our experience is simply a non-starter).

The issue is that the complex engineering applications can cost millions of 
dollars to develop and so piecing together bits that weren't designed to 
interact as the basis for the underlying structures just doesn't work. Even 
bits that are engineered to fit together, often do no.

However, I'm not suggesting that the standard upper ontology is the only 
approach for the engineering disciplines. I'm just saying that it's one 
approach that's being taken seriously and because of the rigour necessary for 
complex engineering applications, it is a viable possible solution.


On Tuesday 06 March 2007 09:26, Danny Ayers wrote:
> On 06/03/07, David Price <> wrote:
> Engineering applications are typically complex
> > and are based on information models/ontologies that have precise
> > definitions - i.e. the information models/ontologies themselves are
> > engineered.
> I'm sorry, you lost me somewhere around here. While I can see that
> engineering systems are likely to be based on precise definitions, I
> don't really see how the creation of information models/ontologies in
> this domain should be more or less engineered than that of other
> domains.
> Also, I may be missing something here, but I would have thought that
> starting from precise definitions would actually simplify the process
> of ontology creation, in that the modelling would be more a case of
> translation from those definitions into the ontology language. In
> contrast, I imagine that a modelling problem in, say, the life
> sciences would typically be trickier, given the greater potential for
> uncertainty due to the complexity of the systems being described.
> To support the engineering disciplines, evolving, fractal
> > ontologies present problems for which there is not currently a solution -
> > or at least not a cost effective solution. That's why the top down, upper
> > ontology approach can be a solution to "the problem" ... we simply have a
> > different problem in the engineering world.
> A question I'd ask here is where you see the (effective) top of such
> an ontology? Are we talking about something like Sowa's lattice of
> top-level categories [1]? It seems to me more likely that the
> sub-disciplines of engineering are likely to have their own fairly
> local requirements - for example the physical/chemical modelling of
> solid-state electronics is likely to have a different emphasis
> compared to that of mathematical modelling of abstract systems like
> operational amplifiers.
> In any case, I don't see a conflict here with the fractal picture -
> even assuming a combined, integrated top-down engineering ontology, it
> would still appear as a big artifact amongst many others of varying
> sizes in the universe of ontologies.
> > I am, of course, painting a far picture wrt what's in use by engineering
> > enterprises today. However, the aims of many are pushing more and more
> > into standards of many varieties - even to the point of standardizing the
> > applications themselves (e.g. the OMG SysML Systems Modeling Language
> > extension to UML).
> That's an interesting point, on the one hand such standardisation
> should make for more effective ontological modelling, on the other it
> may increase the distance between modelling languages designed to be
> generic (such as OWL) and those local to the domains. I don't know if
> the net effect would be increased or decreased interoperability.
> Cheers,
> Danny.
> [1]

Mobile +44 7788 561308
UK +44 2072217307
Skype +1 336 283 0606

Received on Tuesday, 6 March 2007 19:11:51 UTC