OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: object-class and property in 11179

I promised to write up for the list a description of what 11179
means by "object-class" and "property".  That a data element
concept is the conjunction of the two is a basic concept of 11179,
but it isn't illustrated too well.  (Note that we're mostly concerned
with data element *dictionaries*.)

The language in the metamodel is too abstract to be useful; in
particular it lacks examples and is couched in terms of the
metamodel's class structure.

The existing 11179, in Part 1, defines a data element
concept as "A concept, which can be represented in
the form of a data element, described independently
of any particular representation" (def 3.3.15), but of
course that concerns representation, not object class
and property.  A data element is the d.e. concept joined
to a form of representation (e.g., a numeric code).

An object class is defined as "A set of objects. [that's
not obviously correct - a randomly chosen set won't
fit the following] A set of ideas, abstractions, or things
in the real world that can be identified with explicit
boundaries [whatever "boundary" means here] and
meaning [?] and whose properties and behavior 
follow the same rules [that's a bit unclear, too]"
(def 3.3.45).

A property is defined as "A peculiarity common to all
members of an object class" (def 3.3.48).  That's clearly
insufficient, as merely being members of the class is
a peculiarity common to all the members.  But never
mind, we get the drift.  Now for an example.  From Part
1, Section 6:

"Object classes are the things about which we wish to
collect and store data. Examples of object classes are 
cars, persons, households, employees, orders, etc. [sic]
However, it is important to distinguish the actual object
class from its name.  [irrelevant observation deleted] ...
Properties are what humans use to distinguish or describe 
objects. Examples of properties are color, model, sex, age,
income, address, price, etc. [sic]"

So examples would be color-of-car, price-of-order, and

>From Part 1, B.1.2.1 (don't look too closely):

"Suppose a tree is a natural-world object in which we are
 interested. However, we are concerned with any tree, not 
just a particular tree. The characteristic of trees in which 
we are interested is their height. Tree height is an object 
class plus a property (data element concept), but not yet 
a data element, since the appropriate representational form 
has not yet been specified. We can then represent the 
height of a tree by choosing from among the many ways 
of measuring height.

"The term property class might be preferred over property to
name that aspect of a data element. A class of objects
(object class), e.g. people, doesn't have height; each individual 
object, i.e. person, has a height. So for the object class called 
people, height is a property class of that object class. However, 
the term property conforms to common usage, and is used in
this standard."

Now, imprecise as the definitions may be, the point is moderately
clear.  Think of it the other way around:  in order for a data element
to have a value you can store in a database (which is what 11179
is mostly about) you have to pick some property of a person, car,
or order; you also need a representation for the value.  So that's
why a data element is a data element concept plus a representation.

Okay, now, what object class does a DTD belong to?  DTDs, I guess.
What property of the DTD are we interested in?  Plenty of them,
none to the exclusion of others.  We're not constructing a data element
concept "name of DTD" (although in the metamodel something like
"name of data element dictionary" probably exists as a data element
concept); we're using the built-in concept "data element dictionary".

That's why it was possible for me to write up the Docbook samples
without bothering with object-class and property.  We'll need them for
data elements themselves, when we get to them, but we seem not
to need them for DTDs and schemas, considered as such.

regards, Terry

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC