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: 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