[ontology-summit] Roles, fillers, and role relations

[Patrick Cassidy <ontopacas@xxxxxxxxx>]

Re: Mike Bennet’s comment:

 

I'm not clear what problem is being anticipated here:

>  Agreed. This I think is why I am nervous of Patrick's approach of using sub-typing to bring these together.

>  It sound like a recipe for confusion, and I'm not clear how you would combine this with any taxonomy

>  in which things are abstracted to any useful degree e.g. Pump1-1 isA Donkey Pump isA sprinkler

>  part isA Part, and Siemens 450X s/n 123345 is an individual of type Siemens 450X isA diaphragm

>  pump isA rotary pump isA pump isA mechanical device isA device (AND isA IP-66 device isA

> device certified for ingress protection...)

>  It sound like a recipe for confusion

 Well, **I** am not confused, but as you can see from the other discussions of roles, it takes some work to tease apart the fundamental concepts that are combined in our intuitions, no matter what treatment you use.

 

> I'm not clear how you would combine this with any taxonomy

>  in which things are abstracted to any useful degree

   This treatment is combined with a fairly deep taxonomy – COSMO has about 7500 classes and over 800 relations.

 

  I didn’t follow the point of the given taxonomy list.  One can say all of those things in COSMO, if ‘isA’ is the subtype relation, and “Pump 101” is a subtype of “Donkey Pump”.   But from this I cannot see  just how the merged subtyping  of ‘Role’ and other classes causes a problem that you foresee?  In COSMO, "Siemens 450X s/n 123345" would be an instance of all of those types, from both inheritance paths.   Problem?

Perhaps we should discuss how a 'system' could be represented.  One way is to make an abstract  'Specification' for a system consisting or roles and their relations, and in it say, for example, 'the object serving in the role of Pump101 will deliver water to the Location serving in the role of Location202'.  Or, one can create a 'system ontology' that imports the top-level ontology and serves as a specification, and in which instances of Pump101 are in fact physical pumps.  Then one can say 'Pump101 delivers water to Location202'.  I like the latter, in part because it is closer to English usage, and in part because it is simpler.  But one can do it either way in COSMO, as you prefer, and the different ways can be translated into each other.  Use your own language; it can be accommodated.

In all of the efforts from 1995 to arrive at a common upper ontology the biggest barrier (aside from  lack of money) was, IMO, the tendency of some to **exclude** ways of representing things other than their own.  Sometimes this was done for perceived computational efficiency, or just because of lack of time.  But COSMO is being developed as an ontology that does not preclude different ways of representing things, and can serve as an interlingua to translate different ways of representing things into each other.  When I see an ontology with a lot of disjoint partitions, I tend to think "There are more things in heaven and earth than are dreamt of in your ontology".

As for Roles (such as Part) as I mentioned, I prefer being able to merge that 'abstract' notion with PhysicalObjects in a common subtype.   But one doesn't **have to** do it that way.  Thus far, to me, it has seemed the easier route to take.  I think, once you get used to the idea, it will not seem at all confusing.  I think this is similar **in effect** to Matthew's merging of 4D role worms and 4D object worms into common role-objects within specific time intervals.

> Far easier surely to define a separate partition of "Relative Thing" all of which have a single object property

>  of "Identity" which is Independent Thing*. Then have a kind of Relative Thing which is "Part" which

>  of course inherits or narrows that identity object property. In this case, the third order thing in which that "Part" is so

>  defined, is the "System" of which it is a part - indeed, here you have a useful definition of what it means to be a system.
   The top-level type/class ‘Role’ in COSMO may in fact be what you think of as a “Relative Thing".  But I’m not sure what an ‘Independent Thing’ is intended to be, or what the property “Identity” implies.

   PatC

 

Patrick Cassidy

MICRA Inc.

cassidy@xxxxxxxxx

908-561-3416

 

From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mike Bennett
Sent: Saturday, February 04, 2012 1:08 PM
To: rwheeler@xxxxxxxxxxxxxxxxxxxxx; Ontology Summit 2012 discussion
Subject: Re: [ontology-summit] Roles, Fillers, and role relations

 

Ron,

One comment:

On 03/02/2012 13:54, Ron Wheeler wrote:

I was not disagreeing. I think that your analysis and solution looks pretty good to my untrained eye.
I just wanted to throw in a bit more detail to see how they would be handled.

I also wanted to be sure that the important ideas about history and the flow of physical things between roles are addressed in the models being developed.
There is a clear difference between Pump101 which is a piece of equipment and the Siemans 450X serial number 123345 that is currently sitting on the floor connected to all the equipment that Pum101 serves. If these concepts get mixed up, it gets difficult to manage the information properly.

Agreed. This I think is why I am nervous of Patrick's approach of using sub-typing to bring these together. It sound like a recipe for confusion, and I'm not clear how you would combine this with any taxonomy in which things are abstracted to any useful degree e.g. Pump1-1 isA Donkey Pump isA sprinkler part isA Part, and Siemens 450X s/n 123345 is an individual of type Siemens 450X isA diaphragm pump isA rotary pump isA pump isA mechanical device isA device (AND isA IP-66 device isA device certified for ingress protection...)

Far easier surely to define a separate partition of "Relative Thing" all of which have a single object property of "Identity" which is Independent Thing*. Then have a kind of Relative Thing which is "Part" which of course inherits or narrows that identity object property. In this case, the third order thing in which that "Part" is so defined, is the "System" of which it is a part - indeed, here you have a useful definition of what it means to be a system.

Much simpler, surely?

Mike
* or indeed Thing, in case some relative things may be identified in terms of other relative things

I have worked in this area (computer systems to support design and maintenance of petrochemical plants and more recently training of operations staff) for a while and have had to help people develop logical views of equipment and parts from the drawing and simulation stage to operations to maintenance.

Ron


On 02/02/2012 2:19 PM, Patrick Cassidy wrote:

Re: Ron Wheeler's comment (below)

Ron,
   I am unclear as to the point on which you disagree.
[RW] > The thing that sits on the floor and plays the role of Pump101 does have a separate identity.
  Of course, and that is explicitly stated.  It is just not *necessary* to instantiate that identity in addition to the instance of 'Pump101' , unless one wants to talk about it outside of its relation to 'Pump101'. 
An important consideration is that every instantiation of a Role will have time limits on its identity as the thing playing that Role.  Within those time limits, anything said about that instance of 'Pump101' (e.g. the instance named 'Pump101During 2010') will also be true of the separately instantiated entity, **within that time interval**.  If you want to talk about the entity playing the role of 'Pump101'  outside of the time it is playing that role, one can *also* have a separate instantiation (and as I mentioned, manufactured parts usually will have a separate instantiation).  But if one is not interested in 'Pump101During 2010' at any other time, that one instance will be sufficient.  And you can specify the serial number, weight, capacity, etc. of that instance.  It is also possible to specify prior history using a relation such as  'priorHistory' if you want, but it may be easier to do that with relations on a separately instantiated 'Pump' entity.  It's just that, if in some application you don't have to talk about 'Pump101' except during the time interval when that Role is filled by a single object, then you don't have to represent it separately, and that also avoids adding in the role relation from that instance to Pump101.  It's simpler in certain circumstances, and loses nothing from a representation having only Objects and role relations, and Roles that cannot also be physical objects.  Every assertion in one representation can be translated into an assertion using the other type of representation. 

   My question was whether there is something that cannot be represented by the COSMO approach. Of course, in specific applications another representation might be easier to work with, but I would expect any other representation to be logically compatible with and translatable to and from the COSMO representation.

   Did I miss something you were saying?

   Pat Cassidy
   MICRA, Inc.
   908-561-3416
   cassidy@xxxxxxxxx

[PC]
>>   'Part' is a subtype of 'Role' and every 'Part' will be filled by an entity of some other type. Thus in this treatment,
>>  Pump101 would be a subtype of Role and also a subtype of 'Pump' (a physical device).  The physical objects
>>  that fill that Role at any time could also be referred to by the role name ('Pump 101 has failed'). 
>>  The individual object that fills that Role may be identified, but it does not have to have a separate
>>  representation other than as 'Pump101'.  If it is separately instantiated (as most manufactured components
>>  would be), then it would be related to 'Pump101' by a role-filler relation, delimited by the starting and ending
>>  times it plays in that Role.

[RW] > The thing that sits on the floor and plays the role of Pump101 does have a separate identity.
> It probably has a make, model, serial number, a purchase history, possibly a usage history -
> was Pump 209 for a while, was Pump 390 for a while, sat in the parts warehouse for 3 months
> and is now Pump101. It has a BOM with lots of other parts.
>
> Pump101 has none of these things.
>
> Pump101 is part of the fixed assets of the plant. The unit that fulfills that role was possibly
> transferred from the Parts inventory or was purchased with a capital budget.
>
>  Pump 101 is a subtype of "Equipment". The thing on the floor is a subtype of part.
>
> I think that the description of the role-filler relation is a good way to look at the relation between
>  parts and equipment.

_________________________________________________________________

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/

--

Ron Wheeler

President

Artifact Software Inc

email: rwheeler@xxxxxxxxxxxxxxxxxxxxx

skype: ronaldmwheeler
phone: 866-970-2435, ext 102

_________________________________________________________________

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/

--

Mike Bennett

Director

Hypercube Ltd.

89 Worship Street

London EC2A 2BF

Tel: +44 (0) 20 7917 9522

Mob: +44 (0) 7721 420 730

www.hypercube.co.uk
Registered in England and Wales No. 2461068
_________________________________________________________________
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)