SUO: Re: Lifecycle Integration Schema
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
LIS. Discussion Note 5
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
Matthew,
Deleting points adequately covered for now.
New remarks interspersed without indenture.
Re: "thing"
| thing
|
| A <thing> is anything that is or may be thought about or perceived,
| including material and non-material objects, ideas, and actions.
|
| Every <thing> is either
| a <possible_individual>,
| or an <abstract_object>.
|
| NOTE 1. Every <thing> is identifiable within a system.
| System identifiers created by other systems and received
| as part of a data exchange may be stored for future reference
| as an identification, referring to the originating organisation
| or system.
|
| NOTE 2. Every example provided for other entity data types
| declared in this schema is also an example of <thing>.
|
| http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema/lexical/thing.html
JA: You are saying that you are really only thinking about things
that have identifiers in given system, or names in a certain
context of discussion. This is very significant and needs to
be elevated to the level of an explicit principle, instead of
being left implicit in a note that is likely to be neglected,
in other words, relegated to a hidden axiom or constraint
whose consequences are not critically reflected on.
MW: I think it is more that we are saying that if you want to
say something about an object under this standard, you have
to be prepared to give that object an identifier. This is a
practical rather than philosophical statement. You will find
elsewhere under representation a quite general approach to
identification. Providing this "system unique identifier"
was more a piece of practical design. I.e. philosophically
you can ignore it.
There are those among us who would not too quickly dismiss
the philosophical consequences of these practical bearings,
and I am decidedly ONEOF ('EM).
When I was but a flowerchild in the garden of mathematics,
we tended to dismiss what was disaffectionately described
as "matters of mere notation", but when I grew big enough
to pick up a computer and till that garden on my own, the
first big shock of weeds I harvested clued me immediately
into the sine qua non character of "mere notation".
In formal computational terms, a "system unique identifier" (SUI)
of a denoted object is known as a "gödel number" (gnumb). There
are gnumbs for objects in the external world, whether abstract or
concrete, and there are gnumbs for every finite piece of text in
the formal language that we use, the latter gnumbs being what we
are really creating when we "quote" that piece of text.
A measure of how "critically reflective" a formal system can be,
or help us to be, about these external and internal worlds both,
is determined by many pickwickian details of the gnumb function
gnumb : X -> N, where N is the set of nonnegative integers, and
X is typically thought of as being built up in layers from some
initial X_0 that we might treat as the "initial external world".
From another angle, if we think of SUI's as "coordinates" of objects,
that have their meanings relative to a particular frame of reference,
but may be total gödellygeek from the POV of another reference frame,
then what we have here is the task of intercommunication among codes
that we have charged ourselves to discharge.
So there's a lot more to say about this,
but the thrust of it all is that we can
no longer just shove these issues aside,
under whatever category label we assign.
MW: Firstly NOTEs and EXAMPLEs are informative in standards terms.
JA: I probably need a definition of what you mean by "informative".
It sounds like you are saying "not definitive" or "optional".
The way I see it, if it's not avoidable, it's not optional.
MW: See above.
JA: However we gloss it, I am trying to indicate a potential risk of
misinterpretation, of being taken to mean something that is very
different from what one really intends, and there is a potential
danger of, well, glossing over this point if we don't keep all
the constraints and intentions in plain view. There is also
an efficiency loss that comes from trying to do more than
one really needs.
MW: A data model is to support the holding of data about things.
Here we are noting that different systems that might wish to
communicate about some thing may have their own identifier
for it, and that this is not a problem.
JA: Exactly. I am just saying that you are making some significant
assumptions about the relations of signs to things that need to
be made more explicit if they are going to be dealt with more
effectively in a computational/logical framework.
MW: For how we deal generally with signs, I suggest you
look in the representation area, Diagrams 16-20.
Will do.
Jon Awbrey
o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o