Dear PatC,
> 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.
MW: OK. That clears up some of the confusion. I use the term participant for what you call role.
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.
MW: Your role would be a subtype of state_of_individual, and an instance of class_of_state_of_individual, and Role Type would be a subtype of class_of_state_of_individual and an instance of class_of_class_of_state_of_individual. Notice that I refer to time worms that are not whole life individuals as “states”, a more natural word I think. They correspond to the accidental properties an individual might possess. Only necessary classes are instances of class_of_individual.
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,
MW: But now you go back on yourself by saying that a Role is a class. So I repeat, if it is an individual and a class you have a contradiction because a class can have members and an individual cannot.
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.
MW: There is always the question of whether you are interested in a set of individuals or an aggregate. The question you should answer is what is the nature of what is of interest? Am I interested in something I can kick and weigh and operate, or am I interested in something abstract I can count the members of, identify common properties for of its members, and which I can’t operate and weigh and maintain.
MW: Using classes in this case is in my view the wrong choice.
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.
MW: A better approach would be to recognise that there are different worms that have times at which they coincide, or to put it another way, that if you have a worm, you can have temporal parts of those worms, and that these may be coincident with temporal parts of other worms, where in this case one worm is a role, and another worm is an object that might play that role.
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?
MW: I mentioned above that an instance of a role in my scheme is a participant. A participant is a subtype of state_of_individual, will be an instance of a role (your role type), and a part of the activity (instance) it is a participant in.
MW: The parallel is that a system_component is a component of a system, and is classified by a class_of_system_component, which would be its role in the system. You then have an installed_object, that is both a state_of_ordinary_physical_object and state_of_system_component that is the temporal part of the equipment item whilst it is installed as the system component.
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?
MW: I did explain this in my response to PatH. With an activity which has participants as parts, there is a class of activity that the activity is an instance of and roles that the participants are members of. Then there is a relationship between the class of activity and the role that says that members of this class of activity have members of these roles as parts. So it is with systems. For each system, there are system components as components, and where each system is an instance of a class of system and each system component is an instance of a class of system component, then each class of system has a relationship to some classes of system component that says that each instance of the class of system has one or more instance of the class of system component as a system component, which is the bill of materials structure.
MW: This is again separate from different states of different equipment items being installed to act as the system component.
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.
MW: Sorry, to me it is not coherent to think of 4D worms as classes. It just does not compute.
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.
MW: What it seems to me you are struggling with here is that a fact is a fact for ever once you see it outside time. It is always true that Winston Churchill was the prime minister of the UK during WWII. Seeing things in 4D means you see things through the lens of history, rather than the present.
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.
MW: The first thing you need to do then is to disambiguate different usages of the term. For me the ground usage of role is in an activity, which a class of activity has roles, as in a swim lane diagram. The use of role with respect to systems is analogous. A system is not a type of activity, so role used in respect of systems to describe the way the components are connected in the whole is not just a kind of role as used in activities. Finally, you have roles in relationships. For relationships that represent a state that exists between individuals, this can be very like roles in an activity, but there are also relationships between classes, and between classes and individuals, and then the nature of the roles seems not quite the same. But this is as much about the ambiguity of what a relationship is as anything else.
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.
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