Re: [ontology-summit] Roles, Fillers, and Role Relations

[Patrick Cassidy <ontopacas@xxxxxxxxx>]

Matthew H,

   Yes, all that makes sense, but I did not find in that discussion any *logical* problem in allowing a subtype of both Role and PhysicalObject.

  As for the paper of Porter  et al, they gave as a reason to adopt their approach (which is also compatible with and representable in COSMO), that if an Employer is going to be a LegalEntity, and a LegalEntity must be a Person or Organization, then:

 

(c). Because an employer must be a legal-entity, employer must be a sibling

of person and organization. This does not capture our

original assertion that an employer is either a person or organization.

 

But in fact that does not follow.   ‘LegalEntity’ can be defined as the union of Person and Organization, and then an Employer can be a subtype of ‘LegalEntity’ and any instance of ‘Employer’ will be an instance of either ‘Person’ or ‘Organization’, but ‘Employer’ will not be  a ‘sibling’ class that is disjoint from both of those.  If I interpret their desiderata correctly, they seem to have overlooked that method of accomplishing what they want.  I ran it through Protégé-OWL and the reasoner didn’t find any problems.

 

   I appreciate the effort you make to explain real-world requirements.   In looking at your description of the systems and their designs, I don’t see anything that cannot be accommodated within the COSMO ontology.  You can have a separate system Specification with Roles in it, and instantiate those Roles and relate the Role instances to instances of PhysicalObject - if you  prefer.  It would seem that the system requirements could also be modeled as a subontology that imports the parent (e.g. COSMO, SUMO, OpenCyc).  Then all reasoning about system requirements and about actual events could be done by a reasoner using the ontology.   Did you try that method and find it unsatisfactory?  Still, I would not be particularly surprised if your approach works best in your situation.

 

As I have mentioned many times, I think ontologies should be designed to be most useful for their particular application.  In your application, considerations of computational efficiency or perspicuity (people so much prefer to do things the way they always have, and understand that better).  But that principle also means that one should not foreclose options that are more convenient than others.  The COSMO ontology permits reification of instances of  Roles, and they can be used as you and Porter prefer, yet staying  within the COSMO framework.  You just don’t **have to** do it that way.  But I expect that there will be cases (and in particular for language understanding and linguistic communication of machines and people), allowing, e.g. ‘Student’ to be both a role and a real live human being has certain advantages.  If it doesn’t suit your purpose, don’t use it.  As far as I can tell, it is logically consistent with the other approaches used, and can be translated to and from those approaches, using bridging axioms (which are not actually yet present in the OWL version).  As long as we have a foundation ontology that can understand and translate among the different approaches, we can have accurate interoperability among those ontology-based systems.

 

My major concern right now is how to promote interoperability among ontology-driven systems.   For this, one needs a common foundation ontology, but that becomes an insurmountable challenge when one potential user tries to dissuade others from using their own preferred representation(s),  based on some criteria other than logical consistency (or computational efficiency, or perspicuity).  There are different ways to say things that are logically equivalent and can be translated.  COSMO is designed to allow all approaches that are logically consistent.  (logically inconsistent parts must be represented as theories that are not part of the base ontology).   Personal preference is fine for one’s own work, but preferences need to be logically justified when trying to get common agreement for some minimal upper ontology, as we did unsuccessfully on several occasions.

 

PatC

 

Patrick Cassidy

MICRA Inc.

cassidy@xxxxxxxxx

908-561-3416

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew K. Hettinger
Sent: Saturday, February 04, 2012 5:54 PM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: Re: [ontology-summit] System Components

 

RE: Roles, Fillers, and Role Relations

Pat C,

(I hope this makes sense)

"The point is that, although 'Role' is not itself a Physical concept, it

can have subtypes that are physical objects."

 

1) 'Role' should not have subtypes that are physical objects. Reference: Fan, Barker, Porter and Clark, year?, Roles and Purpose. This reference can be found on the Web. If you can't find it I'll provide a link to my copy.
 

2) In systems analysis, architecture and engineering (at least in my practice), it is required that, for example, role and physical (concrete) object taxonomies (and ontologies) be distinct so that at build time one may reason over the architecture description (role descriptions are a part of an architecture description), the physical part descriptions of the design (those things that are **expected** to satisfy the role) , the  design (a description of the system of interest) as a whole (architecture description + concrete part description + context description), the capabilities of the concrete parts, individually or in any combination of these.
 

At Run time

- the architecture description is made manifest in the physical system (the physical system has an architecture) through the interaction of the concrete parts and satisfaction of their roles, based on some criteria. It is possible, and desirable, and in some cases required, that roles may be satisfied regardless of the type of physical part. That is, what is important is the physical parts capability. Not only can a physical part be replaced by one of the same type, but one of a different type. Because, role satisfaction is defined in terms of an group of expectations based on a group of criteria, one may then monitor the capability of the physical part to satisfy the role. A physical part may be required to satisfy many roles. Over time, role satisfaction may deteriorate as a consequence of declining capabilities, external events that affect those capabilities, etc. On the other hand, it is possible in some systems, such as an enterprise, for the roles to change and thus the
  archit

ecture. 

 

Note: any collection of "concrete" parts may be the domain of discourse / world of interest, including language.
Note: a recursive pattern exists in the relations of roles and parts in moving back and forth from (super-)system to (sub-)system - in a SoS. 

 

Ontology, Ontology Systems and moving, forward and backward, between build-time and run-time.
At build time are model systems (symbols sets, rules of construction, and models, e.g ontology), created by modeling systems (engineers and their tools, e.g. ontology engineers, ontology tools), to create/realize run-time modeled systems (which may or may not be an ontology system). The use of ontologies and ontology systems, especially under conditions of multiple build-time systems working collaboratively to create some common run-time system (big systems), is to endure 1) semantic clarity and interoperability between interacting systems (within and between build-time environments and run-time environments, and between run-time and build-time), 2) ensure that what is intended by the modeling system / system engineer, as captured in models, is realized as measured against a set of quality criteria. The analysis models are using the same semantics as the engineering models.
 

The point of all of this is that the above is difficult to do, if at all, with a taxonomy/ontology that explicitly confounds roles and the parts that are expected to satisfy roles.

 

 

Some examples of role relations:

between a role (architecture part) and the (system) part **expected** to satisfy the role

relations between 2 roles

relations between more than 2 roles
relations between any given particular role and the system as a whole made up by the interaction of system parts

there is a collection of role relations within a system boundary, any collection of role relations may be shared between systems
relations may have roles

the networked collection of roles may be thought as a low level architecture layer

--

Matthew K. Hettinger

 

_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2012/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2012  
Community Portal: http://ontolog.cim3.net/wiki/     (01)