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)
|