Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

SUO: RE: Lifecycle Integration Schema




Dear Jon,

See comment below.


Matthew West
Principal Consultant
Shell Information Technology International Limited
Shell Centre, London SE1 7NA, United Kingdom

Tel: +44 20 7934 4490 Other Tel: +44 7796 336538
Email: matthew.west@shell.com
Internet: http://www.shell.com


> -----Original Message-----
> From: Jon Awbrey [mailto:jawbrey@att.net]
> Sent: 02 September 2003 13:10
> To: West, Matthew R SITI-ITPSIE; SUO
> Subject: 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_integrati
> on_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: Then I suggest you consider this attribute deleted for the 
purposes of the use of this material within this forum.
> 
> 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
> 
>