ISO18876

[Van Renssen, Andries SHP OGNL-OGXS]

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.

In my opinion the problem is that you don't distinguish between 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. If objects have a commonality between their
properties, then you model that as if the various individual objects "share"
the same property (class). But that is an inaccurate way of saying: actually
they have individual properties and those properties (plural!) have
commonality.

So I disagree about the idea that a property is a class: individual
properties are individuals. 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.

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.

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