[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: object-class and property in 11179
Regrep Team, I agree with most of Terry's comments regarding data element concepts and his interpretation of 11179. The one area I offer a differing opinion is the topic of whether a DTD should or could be constrained by 11179. I believe we could apply the 11179 principles to all aspects of DTDs. In my opinion, an XML DTD is a representation of a type of document. The object class "document" has many subtypes such as; meeting minutes, contract, purchase order, resume, invoice, dictionary, engineering drawing, formal letter, etc. Each document object could have multiple representation options such as: XML, SGML, PDF, TXT, PS, etc. The properties that one might want to associate to an object such as "document" could include; publication date, author name, revision identifier, etc. Each property could also have multiple representation options - for example, date could be represented by --- July 10, 1998 or 19980710 or 07/10/98 or 07/10/1998 or many other possibilities. In my opinion, the Regrep Team needs to recommend a standard representation form for both the submitted DTD and the properties that relate to the DTD. Ron Schuldt Terry Allen wrote: > 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