Re: SUO: Functional Roles
I've been lurking here, trying to catch up, off and on as time permits,
but this seems like a good time to jump in.
"Function" has been particularly bothersome to me, particularly since
in the (generic, not software) systems engineering community (that I
dwell in, more or less) it is usually used as part of the definition
of "system." I was delighted somewhat when I found Nicola Guarino's
papers about stratification, and the papers of Nicola and Chris Welty
defining unity on the basis of an equivalence relation (e.g., "Towards
a methodology for ontology based model engineering.") Since reading
the later, I've spent a good deal of time trying to understand what
equivalence relation is satisfied by the parts of a hammer or a
bikini.
I don't think function can be removed very far from role. For artifacts,
I think "intended_function" may be useful. "Used_as" is also useful.
Michael Uschold wrote:
>
>I was also thinking that some tables and chairs are always and forever more
>tables or chairs (respectively, of course). Which ones? The ones that
>are, as
>Chris says, are those that are specifically designed and thus intended to
>be a
>table or a chair. Lets stick with just tables, too much typing...
>
>The trouble with this is it brings in 'intention' which seems likely to be a
>nightmare. For example, some confused soul might design something that is
>intended to be a table, but it is so bizarre and out ther that most other
I can't resist adding here: I read that about 100 years ago a young
man named Lionel was in the occupation of setting up window displays
in stores. He had a brilliant idea: a small motorized carrier, running
on a track around the item for sale, carrying a small electric light
pointed on the sale item. Unfortunately, this never caught on. However
the carrier gave rise to Lionel trains, and the lamp was the origin of
the flashlight.
So the bizarre table might well have some other function that catches on.
>people do not even regard it as a table. The intent alone is not enough to
>guarantee it's being a table. So somehow, we may need to get back to some
>of
>the properties that we want for a table. This, as many of us know is
>incredibly
>difficult to pin down.
[snip]
But here, it seems like what we are getting at is "capability."
This is also a useful entry in the ontology. Probably at least as
useful in engineering applications as "intended_function." And
maybe possible to pin down.
John Velman
john.velman@hsc.com