Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[protege-discussion] From UML to Ontologies?

Jonathan Carter jonathan.carter at
Tue Jan 29 11:32:49 PST 2008

In my company, we have used Frames (Protégé 3.3.x) to define our meta model
for capturing any Enterprise Architecture in its entirety. We translated it
pretty easily from the UML documentation of the META model which we had
devised already. Note, it was the meta model for an Enterprise Architecture
model not the model itself that we'd defined in UML before we implemented it
in Protégé Frames. 
We run various reasoning reports against the model that we've captured to
support the various EA processes.

I'd agree with Thomas about being careful how you do sub-typing etc. but in
general I'd have to say that Protégé has been great and the way the classes
work in Frames has been just what we needed. We make a lot of use of the
Class hierarchy that you can build with Protégé Frames.

Hope this helps.


Jonathan Carter - Head of Technical Architecture
Enterprise Architecture Solutions Ltd
Mobile: +44 (0) 7904 198295
Email: jonathan.carter at

Assess your EA maturity at:

-----Original Message-----
From: protege-discussion-bounces at
[mailto:protege-discussion-bounces at] On Behalf Of Thomas
Sent: 29 January 2008 18:20
To: User support for Core Protege and the Protege-Frames editor
Subject: Re: [protege-discussion] From UML to Ontologies?

On Jan 29, 2008, at 4:48 AM, Herwig Wens wrote:

> Dear Community,
> Currently we are kicking off an enterprise architecture program in our 
> company.
> We had a look at Protege and ontologies in general to see we could use 
> this as a way of storing our domain model.
> Meanwhile we already had defined our domain model in UML.
> Being not so familiar with ontologies -- I have a numbe of questions:
> Which ontology flavor is the best option for describing a domain 
> model?
This is a tough question to give a one-line answer to.

A lot depends on what type of domain model you want to describe, and what
sorts of reasoning you wish to do with that model.  You would need to use a
language and set of tools that allow you to express your domain model
correctly and perform any necessary reasoning.

Frames are a bit closer to an object-oriented model.  OWL is a strict
logical model, but comes with stronger semantic guarantees and well- founded
reasoners. Frames support default values, whereas OWL is strictly monotonic.
There are also some additional considerations, so if you had some specific
issues or questions, it would be easier to provide guidance.
> I have tried the default flavor that come with the 4alpha versions, 
> but I found it very difficult to translate the UML model to this 
> ontology flavor.
> By looking at the tips and tricks, It sounds that Frames is a better 
> flavor? Is this true?
> Has anyone has some tips and tricks in deriving an ontology from UML?
> E.g., a part where I'm struggling with is to model a composite in OWL:
> <C9565875.gif>
Well, one thing to be careful of is overuse of the subtyping, just because
that is the most prominent relation shown in UML as well as in Protege.

 From your diagram, it appears that you have the composite PrincipleSet as a
subtype of Principle.  This may be justified, but my initial reaction is
that a Set of Principles is not, in itself a Principle.  Could you use a
PrincipleSet anywhere you use a Principle?  Can PrincipleSets contain other

In any case, the OWL model would look something like this pseudo-syntax.

   owl:Class Principle
             => all memberOf PrincipleSet
                atmost 1 memberOf

   owl:Class PrincipleSpecific
             =>  subclassOf Principle
                 exactly 1 rationale
                 atleast 1 implication
                 atleast 1 assurance

   owl:Class PrincipleSet
             => atleast 1 hasMember
                all hasMember Principle
                subclassOf Principle ??????

   owl:ObjectProperty hasMember
   owl:ObjectProperty memberOf
           inverseOf hasMember

If it turns out that a PrincipleSet is not, in fact a Principle, but merely
a collection of Principles, then you may be able to simplify your model by
coalescing the Principle and PrincipleSpecific classes and having
PrincipleSet just be a Set of Principles but with no subclass relationship.
You might also find that you want to use a more specific membership
property, although you can use a general membership.

protege-discussion mailing list
protege-discussion at

Instructions for unsubscribing: 

More information about the protege-discussion mailing list