ontology-summit
[Top] [All Lists]

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

To: ontology-summit@xxxxxxxxxxxxxxxx
From: Patrick Cassidy <ontopacas@xxxxxxxxx>
Date: Thu, 2 Feb 2012 14:19:13 -0500
Message-id: <CAGvG7ZE4YcNveVfqyUEUSoQsEQLvPBWfgjY87F6kwDOsewk-gA@xxxxxxxxxxxxxx>
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/     (01)
<Prev in Thread] Current Thread [Next in Thread>