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

[Patrick Cassidy <ontopacas@xxxxxxxxx>]

MatthewW,

  > The problem with a subtype of both Role and PhysicalObject is that the instances of Role are themselves classes

 

     That Is not the usage in COSMO; if one views an ‘instance’ of a Role as a specific whole 4D worm through space-time, then this is actually represented in COSMO by a class which is a *subtype* of the generic  ‘Role’.   I think that this has the same effect as your treatment, using a different notation.

     Each subtype of ‘Role’ in COSMO is also an instance of the metaclass ‘RoleType’ (which I suppose would be a  Class of Class in your ontology.  Perhaps COSMO ‘RoleType’ is what you think of as the generic  ‘Role’?)  Then in COSMO any *instance* of a Role is in  fact a TimeSlice of that Role (if it is an individual 4D worm) or of some subclass of that Role (if it has more than one 4D worm member) -  this is an idiosyncratic usage that is not fully axiomatized in COSMO at present, as COSMO is still in OWL format, but it works logically; each instance must exist in a specific TimeInterval.  If that instance/TimeSlice is also an instance of some object (it doesn’t have to be), it would also be a TimeSlice of that Object.  This can be done because a Role in COSMO is formally a Class, even though one might prefer to view individual worms through space-time as individuals (you can do that if you like, but that is not the logical treatment).     If one wants to think of each subtype of ‘Role’ as a class (as in COSMO), but also wants each 4D ‘Role’ worm to be an individual, then such a worm can be thought of as a class with a single instance.  I think this is logically sound.

It seems to me that your treatment and COSMO accomplish the same effects
using different notation.

   If one were to treat each specific role worm through space-time only as an individual, then it would not be possible to have formal instances, only time slices, and then, as you sate,  it would not be possible to have instances of both Role and PhysicalObject.  But that is not the logical definition in COSMO.  The effect is the same, but the format in which the assertions are made differs in the different treatments.

 

   I don’t recall noticing that particular treatment you mention – that instances of ‘Role’ are classes.  What are the instances of those instances of Roles called?   Are they time slices of an individual Role?

 

  There are other considerations.  For example, if one has a specification for a particular type of device which is a system, and there may be many devices of that type manufactured, then the ‘Role’ of say Pump101 in that specification would have many individual space-time worms as instances.    Then it would appear to be a class.  But if you had a specification for an individual unique system, the Role might well be only one such 4D worm.  How do you distinguish such Roles?

 

   One reason to treat Roles as all subtypes of the generic ‘Role’ (and instance of ‘RoleType’) is that one can be agnostic, when convenient, of just how many subclasses there might be.  The role ‘Student’ for example may have many subtypes and many role fillers, and many 4D worms as subtypes.  If one wanted to think of individual 4D worms as individuals, not classes, then it would be necessary to specify that a particular Person fills a Role in some specific a TimeSlice of some specific 4D worm, which would then have to be instantiated.  I find it easier to just specify that an instance of  Person is an instance of ‘Student’ in some time interval, and specify the time interval.  This way I don’t have to identify the specific 4D worm.

 

However, if one defines a Role subtype generated by an Event, e.g.  ‘The first student to register in class X by Professor Y in year Z’ that Role would have to be an individual worm in space-time, and once that role is filled by a Person, that Person continues to fill that Role forever.  This is different from Pump101 which may have many fillers, and the DramaticRole of ‘Hamlet’ which may not only have many fillers, but may have as many 4D worms as there are performances.

 

  Trying to formally capture all of the intuitions about different kinds of ‘Role’ takes a bit of work, and can be done in different ways.  My goal is to find a logically sound representation that can support language understanding, and also be translated into other representation formalisms when needed.

 

 

 PatC

 

Patrick Cassidy

MICRA Inc.

cassidy@xxxxxxxxx

908-561-3416

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Matthew West
Sent: Sunday, February 05, 2012 2:12 AM
To: 'Ontology Summit 2012 discussion'
Subject: Re: [ontology-summit] Roles, Fillers, and Role Relations

 

Dear Pat,

 

The problem with a subtype of both Role and PhysicalObject is that the instances of Role are themselves classes, whilst the instances of PhysicalObject are particulars. This means of course that the instances of a subtype of an intersection of these two would be both a class and a particular, which are normally considered disjoint.

 

Regards

 

Matthew West                           

Information  Junction

Tel: +44 1489 880185

Mobile: +44 750 3385279

Skype: dr.matthew.west

matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx

http://www.informationjunction.co.uk/

http://www.matthew-west.org.uk/

 

This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.

Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.

 

 

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Patrick Cassidy
Sent: 05 February 2012 02:52
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: Re: [ontology-summit] Roles, Fillers, and Role Relations

 

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)