ISO18876
Bernd G. Wenzel
bg_wenzel at csi.com
Tue May 14 13:26:52 EDT 2002
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
More information about the wg10
mailing list