ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Roles, Fillers, and role relations

To: rwheeler@xxxxxxxxxxxxxxxxxxxxx, Ontology Summit 2012 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
From: Mike Bennett <mbennett@xxxxxxxxxxxxxxx>
Date: Sat, 04 Feb 2012 18:07:44 +0000
Message-id: <4F2D73F0.6010003@xxxxxxxxxxxxxxx>
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)
<Prev in Thread] Current Thread [Next in Thread>