Register
 
 
 


Reply
  Author   Comment  
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #1 
These comments were input to The Open Group publications e-mail address.

Dear Madam,  Sir,

First of all I wish to congratulate you with the work referenced under subject.
Particularly the documentation (.pdf ) is of great value and shows that a big effort was at the basis of this result.

Of course many points of discussion may subsist but that not the intention of this mail. The fact is I have some reflexions and questions which may be taken into consideration when a review of the ontology will be considered.

Please find them hereby,not as a criticism but as a means of improving your already good document.

Open questions

Would it be possible to avoid the term "instance"?

Motivation: there is no instantiation process of classes in semantic web technologies.

The foundations for semantic technologies are set theory. One individual concept may be a member of a set (called class in owl), eventually satisfying criteria set forward. But in no way there is any instantiation. The usage of the term instantiation turned to be a substantial  barrier in the comprehension of the basics in those technologies.

Several classes

1.     Why are the minimum 0 cardinalities specified for properties in relation to several classes (Task, Composition, Service, Human Actor,…) ?

2.     If the maximum cardinality is 1, why is the "Functional" characteristic of properties not used?

3.     Many classes are made disjoint. Why is the opportunity to learn from the individuals not taken?

On the properties

Many properties have their domains and rangees defined. Is the ontology not too much a translation of a class diagram? Do we not lose to much possibilities to learn from the individuals?

Specific content

Page 10, chapter 2.6.3

Why are the individuals Joe, Mary, John, Jack been made members of class Element? I would have expected them to be members of class Human Actor.

Page 15, chapter 3.3.2

Have you considered using properties to represent roles?

If yes, what are the reasons to choose for a non-specified subclass of Element called "Role" ?

Page 19, last paragraph of chapter 3.5

"Tasks are naturally thought of as being….then the natural cardinality is that each instance of Tasks is done by at most one instance of Human Actor."

What was the motivation for this restriction?

Page 22, last line of the second paragraph in chapter 4.3

"Conversely, any instance of Element may perform more than one service or none at all".

This is contradictory to what is specified on page 19, last paragraph of chapter 3.5. (See previous point)

Since Human Actor is a subclass of Element, the rule for Human Actors is applicable to the Elements, members of Human Actor class. I propose to skip the restriction in chapter 3.5.

Page 25, chapter 4.5

Why is Class ServiceContract made disjoint with those many classes (8 in stead of the 3 mentioned in the paper) ? Whould the use of the associated properties not form a nice opportunity to discover more contracts?

0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #2 
First, thanks for these comments, which will help us improve the quality of the standard! I am starting with a reply to the first point, and will respond to the others one at a time.

On the question of instances, we could think about using the term "member" instead of "instance". Personally, I normally talk about "members of a set" and "instances of a class," but I wouldn't mind saying "members of a class" which I think would mean "members of the extension set of a class."

However, the OWL Reference (http://www.w3.org/TR/2004/REC-owl-ref-20040210/) does talk about "instances." It says at the start of Section 3 that, "Classes provide an abstraction mechanism for grouping resources with similar characteristics. Like RDF classes, every OWL class is associated with a set of individuals, called the class extension. The individuals in the class extension are called the instances of the class. A class has an intensional meaning (the underlying concept) which is related but not equal to its class extension. Thus, two classes may have the same class extension, but still be different classes."

So, while I agree that OWL does not have a process of instantiation in the same way as (for example) a programming language such as Java, I do think that it is perfectly reasonable to use the term "instance" in connection with an OWL ontology.
0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #3 
Why are the minimum 0 cardinalities specified for properties in relation to several classes? These cardinalities were discussed by the project team and represent the team's consensus view. The reasons for the decision are often included in the standard. For example, the section on Tasks says that:
Tasks are naturally thought of as being done by people or organizations. If we think of tasks as being the actual things done, then the natural cardinality is that each instance of Task is done by at most one instance of HumanActor. Due to the atomic nature of instances of Task we rule out the case where such an instance is done jointly by multiple instances of HumanActor. The cardinality can be zero if someone chooses not to instantiate all possible human actors. On the other hand, the same instance of HumanActor can (over time) easily do more than one instance of Task. The does property, and its inverse doneBy, capture the relation between a human actor and the tasks it performs.

We could discuss making changes to these cardinalities in a future version if there is good reason to do so.

0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #4 
If the maximum cardinality is 1, why is the "Functional" characteristic of properties not used?

This is a good question. I don't think it would make any difference technically, but it might make the ontology more readable.
0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #5 
Many classes are made disjoint. Why is the opportunity to learn from the individuals not taken?

In defining the ontology, the project team was capturing its common understanding of the terms concerned. It did not have a set of individuals that it was trying to classify. So, for example, HumanActor is stated to be disjoint with Service because the team's understanding of "human actor" and "service" was that they are completely different concepts, with no possibility that anything could be both a human actor and a service.
0
eddyvanderlinden

Registered:
Posts: 2
Reply with quote  #6 
Thank you for your vision and answers to my questions.
I see that the reason for many answer lies in the fact the description starts from a UML diagram.
The type of diagram also W3C uses to demonstrate the functional specification (http://www.w3.org/TR/2012/REC-owl2-syntax-20121211/). It makes a difference if we start from the foundations of owl and use UML to describe the functions, compared to starting from an UML class diagram and then elaborating on an owl ontology.
If we would have the ambition to make the ontology DL-compliant, there is even less reason to start from an UML diagram.
I recon the SOA ontology is nice and well documented, congratulations for that. In other cases I found the translation UML to OWL quite clumsy.
That's why there is this article on the difference class diagram and their possible foundation (MOF or ERM): http://fadyart.com/en/index.php?option=com_content&view=article&id=135:why-not-to-use-entity-relationship-diagrams-to-describe-semantic-assets-if-owl-ontologies-are-considered&catid=46ntology-general
Of course I am eager to learn about your vision on these statements.

We elaborated also on a semantic description of the Enterprise Architecture which could be taken into consideration by the European Commission. You may find it here: http://fadyart.com/en/index.php?option=com_content&view=article&id=134:a-core-civil-services-ontology&catid=1:latest-news&Itemid=93
As you can read from the architectural document, the ontology is ment to be an executional architecture.

The SOA ontology of the Open Group is intended to become part of this executional ontology.
That's why we would like to adapt the Open Group's ontology to make it executional too.
The motivation for our questions lies fully there
0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #7 
It is a fair comment that the ontology is written somewhat from a metamodeler's perspective. I'm not sure that there is a technical difference between a metamodel and an ontology, but there is certainly a big difference in the approaches taken by people with metamodeling and ontological backgrounds.

It is technically a valid use of OWL to think first about classes, then about the relations between classes, and then translate these into OWL relations with range and domain classes. And this is the approach that many people who are used to UML and metamodels will take. But people who are used to ontologies will be more likely to start by looking at the relationships. There are probably other differences. This is an important one.

This ontology is - as all useful ontologies are - a compromise agreement between a group of people on how they will use a particular set of terms. Many of the people involved in its development had a metamodel background, and this probably explains why the result is as it is. It may be that an ontology defined using a different approach would have been of slightly more practical value. To have something of practical value at all, you must have community consensus, and that was what we were able to achieve.
0
eddyvanderlinden

Registered:
Posts: 2
Reply with quote  #8 
Fully agree with the comments above.
Thanks for sharing your thoughts.

Kind regards

Eddy
0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #9 
Why are the individuals Joe, Mary, John, Jack been made members of class Element? I would have expected them to be members of class Human Actor.

They are given as examples of instances of Element in the chapter on System and Element. The next chapter, on HumanActor and Task, explains that they are instances of HumanActor, which is a subclass of Element.
0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #10 

Have you considered using properties to represent roles?

If yes, what are the reasons to choose for a non-specified subclass of Element called "Role" ?

The whole area of actors and roles is somewhat confused, with different communities understanding these terms in different ways.

We chose not to define a “role class”, as we believed that using Element with the represents property is a more general approach which does not limit the ability to also define role-based systems. We considered that, for all practical purposes, there is simply a “role subclass” of Element, a subclass that we have chosen not to define explicitly.

I don't think we considered using properties to represent roles. This is an interesting idea, and might be a more powerful way of expressing specific roles. But to express the idea that something "is a role" we would then have to define a role class whose instances were properties or, with the approach that we took, make "represents" a relation between instances and properties. I suspect that either of these would mean going to OWL-FULL, which we didn't (and don't) want to do.

0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #11 

"Tasks are naturally thought of as being….then the natural cardinality is that each instance of Tasks is done by at most one instance of Human Actor."

What was the motivation for this restriction?

This is saying that our concept of "task" is that of an atomic activity performed by a single person or organization, as opposed to a co-operative process. This is the way we use the term "task"; we recognize that other communities use it in different ways.

We were heavily influenced in this choice by our desire to align with Business Process Modeling Notation (BPMN). We recognize that BPMN and SOA are related, and believe it is important to have conceptual commonality with the BPMN community on areas of overlap. Members of that community participated in our discussions and helped us to achieve alignment. (Having said which, this is an Open Group standard. We want to align with other communities but take responsibility for the result and do not claim to speak for those communities.)

0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #12 

"Conversely, any instance of Element may perform more than one service or none at all".

This is contradictory to what is specified on page 19, last paragraph of chapter 3.5. (See previous point)

Since Human Actor is a subclass of Element, the rule for Human Actors is applicable to the Elements, members of Human Actor class. I propose to skip the restriction in chapter 3.5.

We do not believe that there is a contradiction here. Service and Task are distinct concepts. Performance of a service typically requires carrying out a number of tasks. A common case is where an organization performs a service and each task is carried out by a different member of the organization.

0
cjh

Super Moderators
Registered:
Posts: 102
Reply with quote  #13 
Why is Class ServiceContract made disjoint with those many classes (8 in stead of the 3 mentioned in the paper) ? Whould the use of the associated properties not form a nice opportunity to discover more contracts?

I'm not sure I understand this question. ServiceContract is stated to be disjoint with two classes: HumanActor and Task. This is part of our understanding of these three concepts.

I'm not sure how you would "discover" a contract. I would say that a contract comes into existence when two or more parties agree to create it.
0
Previous Topic | Next Topic
Print
Reply