humanmarkup-comment message
[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
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: 'Rex Brooks' <rexb@starbourne.com>,Ranjeeth Kumar Thunga <rkthunga@interposting.com>,humanmarkup-comment@lists.oasis-open.org
- Date: Thu, 05 Dec 2002 09:01:45 -0600
Title: Re: [huml-comment] Request for a motion on PC-33 -Sect
I'm
not sure "derived" is exactly right. If in fact, one can't say it is
a physical
characteristic native to an instance, one can say it can be created as a
sign
whose
prototypical properties (in the Sowa sense of a prototype as a set
of
properties that taken together, determine set membership) are derivable
from
HumanML primary types. Using the example I provided
earlier,
Race:
A =
Asian
B = Black
I = Indian
W = White
U =
Unknown
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
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