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.
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
|
rwheeler.vcf
Description: Vcard
_________________________________________________________________
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)
|