OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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




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