[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 age-of-employee. >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