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

SUO: RE: Lifecycle Integration Schema -- Matthew West




Dear Jon,

See comments 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: 01 September 2003 14:16
> To: West, Matthew R SITI-ITPSIE
> Cc: SUO
> Subject: Lifecycle Integration Schema -- Matthew West
> 
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> LIS.  Lifecycle Integration Schema -- Matthew West
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> LIS.  Discussion Note 1
> 
> o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o
> 
> Matthew,
> 
> I will make this thread independent of my other questions,
> starting at the top and trying to think about how I would
> formalize the LIS ontology or data model in logical terms,
> asking for clarification as I go.  I always try to formalize
> things in layers -- if there is a layer that I can formalize
> in propositional calculus (pure boolean functions and so on),
> then I will do as much as I can of that layer first;  if there
> is a layer that I can handle in ordinary naive set theory, then
> I will do that first, putting off questions about the exact axioms
> until they come up, not to mention nonwellfounded set theory, which
> nobody should think is going to make life one bit easier for them.

MW: Sounds good to me.
> 
> | 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

Notes & Queries.

| A <thing> is anything that is or may be thought about or perceived,
| including material and non-material objects, ideas, and actions.

A statement that begins "An X is any X that ..." is problematic.

I will pass it by for now, and treat it as a comment that tells me
something about how you plan to use the word "thing", in some actual
or potential relation to the things that you call "perceptions" and
"thoughts", and applicable inclusively to all of the things that you
call "actions", "ideas", "material objects", and "non-material objects".

MW: It is normative text in the standard, but you are right not to
worry too much about it. Thing is nearly equivalent to John Sowa's TOP, but
within a 4D ontology, so a continuant is not an ISO15926 thing, since it
doesn't fall within the paradigm. In a lattice of theories it would be
the root for this 4D ontology, and fall somewhere under John Sowa's TOP.

MW: For the purpose of the SUO we would need to reword this definition
at some point.

| Every <thing> is either
| a <possible_individual>,
| or an <abstract_object>.

This is an informative statement.  

MW: But normative in standards terms.

It specifies a mutual constraint
on the applications of the three terms, "thing", "abstract_object",
and "possible_individual".  Moreover, it's a constraint that can be
captured in zeroth order terms (boolean algebra, monadic predicates,
propositional calculus, sentential logic, etc,) and expressed very
succinctly in my favorite language for same, so I will capture it
immediately in the following form:

( thing ,( abstract_object ),( possible_individual ))

Roughly speaking, taken as an assertion, this says that every thing
is either an abstract_object or a possible_individual, but not both.

MW: Correct. If had had gone a couple of lines down you would have
found the following EXPRESS:

ENTITY thing  
 ABSTRACT SUPERTYPE OF  (ONEOF(possible_individual, abstract_object));  
 
MW: ABSTRACT means it is only instantiated through its subtypes,
and ONEOF means one or the other but not both. ABSTRACT is indicated
in the diagram by the (ABS) in the entity type name, and the ONEOF
is indicated by the "1" by the subtype/supertype tree.

MW: We often did not bother to give these statements informally if
the information was contained in the formal EXPRESS.

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

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: Firstly NOTEs and EXAMPLEs are informative in standards terms.

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.

| NOTE 2.  Every example provided for other entity data types
| declared in this schema is also an example of <thing>.

Okay for now, as long as it's just a comment.

MW: It is, see above.

There are some generic issues already arising here,
that come up in every discussion of this type, but
I'll need to think about some new ways to say them.

Jon Awbrey

o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o~~~~~~~~~o