[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [huml-comment] Request for a motion on PC-33 -Section 4.4.6-r ace
Bullard, Claude L (Len) wrote: > Race: > > A = Asian > B = Black > I = Indian > W = White > U = Unknown What if my father was half Asian and half White, and my mother half Black and half White; what would I be? Given that this attribute is just of type xs:string and not an enumeration (not that such a constraint would help) does not really help. The information contained is to be unpredictable at best. Putting ethical arguments aside, this attribute does not serve much. Now, if a complex type could trace races up my bloodline, that would be something. Yup, that would be pretty objective... Manos > > one sees a term followed by a codelist. What HumanML could provide > would be a set of properties for the term, race, which could then be used > to make a selection from that set given an instance. That set might > include rules or might be a simple prototype such as slots with > values for physical > characteristics common to members of the set, historical origins, and > so on. > (In practice, this is hard to do, but I think that difficulty itself > is valuable > in focusing the community of interest's use of the term; that in fact, > the real value of the term will decline.) > > Note: the same approach would apply to declaring prototypes for > races of trolls, woodland, plains, mountain, or otherwise. So this > is not special pleading, but precisely how HumanML is intended > to be used. > > Thanks to Dennis for pointing this one out. It provides a good > example of how HumanML can be applied to a term of contention > such that typical users of the term can clarify precisely how > this term is defined below the level of the initial codelist. > > len > > > > -----Original Message----- > *From:* Rex Brooks [mailto:rexb@starbourne.com] > > I would prefer a stronger reason than that it simply can be shown > to be non-objective despite current usages, and it can be derived > from the existing PBS in a secondary schema, and it can be > imported or declared from other interoperable resources. Those are > sufficient, but not compelling reasons, whether reapplicable or not. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC