ISO18876

[West, Matthew R SITI-ITPSIE]

Dear Andries,

See my responses 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.r.west at is.shell.com
Internet: http://www.shell.com


> -----Original Message-----
> From: Van Renssen, Andries SHP OGNL-OGXS 
> Sent: 21 May 2002 09:52
> To: 'Bernd G. Wenzel'; West, Matthew R SITI-ITPSIE
> Cc: Julian Fowler (E-mail); WG10 (E-mail); Howard Mason (E-mail);
> ISO18876 (E-mail); Gerry Radack (E-mail); Meinolf Gröpper; 
> Teijgeler, H
> FLUOR-HAA
> Subject: RE: ISO18876
> 
> 
> Dear Matthew,
> 
> It is not only Bernd. At least I agree with Bernd on his 
> issue on the concept of class.
> The result of the current model will be that we keep 
> struggling with the distinction between pluralities and classes.

MW: I am quite certain that some will struggle with many of the
distinctions, such as those between pluralities and classes. I suspect
it was ever thus and ever will be.

MW: However, I should point out that you have addressed your comments
to the wrong standard. ISO18876 is an architecture and methodology, and
not a model. It takes absolutely no position on what a property or class
is as far as possible (unfortunately it is impossible to avoid mentioning
the words/concepts in a broad sense). 
> 
> In my opinion the problem is that you don't distinguish 
> between commonality of properties and sharing of a property.

MW: I don't understand what you mean by "commonality of properties 
and sharing of a property".

> I think that this lack of distinction is also the cause why 
> you keep saying the a property is a class. 

MW: If it looks like a duck, acts like a duck and quacks like a
duck ...

> If objects have a 
> commonality between their properties, then you model that as 
> if the various individual objects "share" the same property 
> (class). 

MW: They (individuals) do not share anything except membership of 
the same class (property) under ISO15926.

> But that is an inaccurate way of saying: actually 
> they have individual properties and those properties 
> (plural!) have commonality.

MW: According to your view (to which you are entitled).
> 
> So I disagree about the idea that a property is a class: 
> individual properties are individuals. 

MW: The closest thing to your individual property in ISO15926 is
a possible_individual that is a temporal part of a whole_life_
individual and is a member of a particular property. That is
certainly how I would map what I understand as your individual
property into ISO15926.

> And it is too 
> simplistic to 'declare' that individual properties do not 
> exist. I know that you prefer not to model individual 
> properties, so in your model they do not appear. That is your 
> choise and will have its consequences and will provide 
> limitations to the applicability of the model. But as you 
> say, it is a valid choice, but not mine.

MW: Indeed, and we were told to only support one way of saying
things where this could be practically achieved.
> 
> Nevertheless I think that it would clarify the terminology if 
> you would use a consistent naming convention and use the name 
> "class_of_property" for the class. Now you get anomalies in 
> the subtyping hierarchy, against which I raised an issue on 
> 15926-2, as you know. Now your naming convention results in 
> confusion, because if other people, such as myself, talk 
> about a property we mean an individual.

MW: You are of course quite entitled to use property in the 
way that you do. Property is a word that is used in any ways.
Some people will be unhappy however we define it, so the best 
I think we cna do is define the usage we do make, which we have
done.
> 
> Regards,
> Andries
> 
> -----Original Message-----
> From: Bernd G. Wenzel [mailto:bg_wenzel at csi.com]
> Sent: 14 May 2002 19:27
> To: West, Matthew R SITI-ITPSIE
> Cc: Julian Fowler (E-mail); WG10 (E-mail); Howard Mason (E-mail);
> ISO18876 (E-mail); Gerry Radack (E-mail); Meinolf Gröpper
> Subject: Re: ISO18876
> 
> 
> Matthew,
> 
> you wrote:
> 
> >  - I don't see a need, not even a justification for the 2
> > normative references.
> 
> MW: The two references are for the Information Object
> Registration
> in Annexe A.
> 
> BGW: I'm aware of this, but a normative reference makes the
> referenced standard an integral part of the referencing standard.
> I don't see this need; I'd rather think, that a bibliographical
> reference should be enough.
> 
> You also wrote:
> 
> >  - Your example at the definition of the term "individual"
> seems
> > to support my point. Applying your definition of "class",
> > "starship enterprise" is a class containing several
> individuals,
> > such as a contemporary NASA shuttle, a starship commanded by
> > James T. Kirk, and another starship commanded by Jean Luc
> Piccard
> > about 100 years later.
> 
> MW: The only sense here in which "starship enterprise" is a class
> is
> the one in which it is the class of physical objects that bear
> the
> name "starship enterprise" and that identify the starship
> "Enterprise",
> (the James T Kirk one). I'm afraid this is part of how you
> misunderstand
> the way we treat representation, but we are trying to improve the
> way
> we explain that. In the example, it is what is referred to that
> is the
> example, not the text.
> 
> BGW: There is a lot to say here, such as:
>  - "starship" is the identifier of a class of class of physical
> object
>  - "Enterprise" is the identifier of some physical objects,
> including an aircraft carrier, a space shuttle, etc.
> I'd propose to replace the example for a fictional object by
> something more unique, or use both the Enterprise commanded by
> James T. Kirk and the Enterprise under the command of Jean Luc
> Piccard as examples of 2 different fictinal objects.
> 
> Finally you wrote:
> 
> >  - Annex D seems to address my main issue, unfortunately not to
> > my satisfaction. You say,
> 
> MW: To be precise it is Julian, but no matter.
> 
> > that the data type <monument> is a
> > class, the members of which are data instances, such as #100. I
> > tend to disagree. The data type <monument> is the definition of
> > this class, not the class (=collection) itself.
> 
> MW: In this we genuinely disagree. The definition you talk about
> is really some set of properties that all members of the class
> possess. Now properties are classes, so this means that the class
> is the intersection of the property classes. The intersection of
> the property classes is then both the definition of the class,
> and the membership.
> 
> BGW: In mathematical logics it is considered useful to
> distinguish between a set (in your terminology class) itself and
> its characteristic function. The latter is a formal (at least in
> all useful cases) definition based on which I can decide whether
> or not an object belongs to the set. If we want to contribute to
> the solution the data integration problem, we cannot do so
> without bridging the gap between data and reality. The
> characteristic function is the means to bridge this gap.
> 
> MW: I appreciate there can be different views on this, but the
> view we take is quite valid. Given that this is an example in
> an informative annex, and some view has to be taken, I think
> it is reasonable that we should take ours.
> 
> > In a standard
> > trying to cover the integration of industrial data for
> exchange,
> > access, and sharing we need to be very precise and explicit,
> when
> > it comes to the relationship between reality and the data
> world,
> > especially as the latter is part of the first.
> 
> MW: I believe we have been, even if we have not always reflected
> your own views on some matters.
> 
> BGW: See my comment above
> 
> 
> :-) Bernd
> 
> ---------------------------------
> Bernd G. Wenzel
> Ganghoferstraße 7b
> D-83043 Bad Aibling
> Germany
> 
> Phone: +49-8061-37232
> Fax:      +49-8061-92018
> Mobile: +49-170-9983565
> Email:   bg_wenzel at csi.com
>