Okay, here is Doug's proposal the way I understand it, in table form (please use non-proportional font to view it): [by the way, I like Addison's proposal, too] (Language-)Type Scope Number Examples Proposal Doug Ancient Individual Ancient Constructed Individual Constructed Extinct Individual Extinct Historic Individual Historic Living Individual - Living Macrolanguage Macrolanguage Special Special 4 mis/mul/und/zxx Special - Collective 113 Collecti(ve|on) - Local 520 Local I think this goes into the right direction. I'm not sure I understand the distinction between Ancient, Extincts, and Historic, but I don't bother. I'm marginally affraid that we will have to reopen the WG if in the future, there is a case where the above scheme fails. Therefore, I suggest to clarify by saying (very roughly) "the *Foo* field contains the information in the Type and Scope fields of ISO 639-3. Values of 'Living' for 'Type' and 'Individual' for Scope are default and therefore omitted. If both values are the same, only one word is used. The order of the values is undefined. If the field is empty, it is not used." This would give us the freedom to have Language-Type: Ancient Macrolanguage or Language-Type: Macrolanguage Ancient if something like that ever becomes necessary in the future. Also, I don't care about Collective vs. Collection (I think we therefore best leave it as is), but I think changing "Local" to "Private" would help the readers of the registry, because that's the general IETF terminology. Regards, Martin. At 15:27 08/06/02, Doug Ewell wrote: >Here are some statistics, taken from the current ISO 639-3 data, which >may >be relevant to my suggestion to create an informative field in the > >Registry that combines the "scope of denotation" and "type of language" > >fields from 639-3. > >The "scope of denotation" field includes the following >values: > >- Collective >- Individual >- Local >- Macrolanguage >- Special > >The >"type of language" field includes the following values: > >- Ancient >- >Constructed >- Extinct >- Historic >- Living >- Special > >Although these are >somewhat disjoint data sets, the data contained >within the two is >currently constrained in such as way that it can be >combined into one >field, as seen below: > >1. All codes of type "Ancient," "Constructed," >"Extinct," and "Historic" >are of scope "Individual." > >2. All codes of >scope "Macrolanguage" are of type "Living." (In fact, >it seems unlikely >that a non-living language would be designated a >macrolanguage in the >future.) > >3. All codes of scope "Special" are also of type "Special," and >vice >versa. These are 'mis', 'mul', 'und', and 'zxx'. > >4. Codes of scope >"Collective" do not have a designated type. These are >the collection >codes traditionally associated with 639-2, and now >unambiguously >associated with 639-5. There are 113 of these. > >5. Codes of scope "Local" >do not have a designated type. These are the >520 private-use codes 'qaa' >through 'qtz', which occupy just one listing >in the LSR. > >Given this, we >could add an optional "Scope" field (or pick a better >name) to language >and extlang records in the LSR with exactly one of the >following values, >with no ambiguity: > >- ancient >- collective (or "collection") >- >constructed >- extinct >- historic >- local >- macrolanguage >- special > >and >omit this field for the language subtags that are "individual" and > >"living," which are 89.8% of the total (7019 out of 7816) and thus can >be >treated as the default. > >Alternatively, if combining the fields is too >distasteful for some, we >could add separate "Language-Type" and "Scope" >fields corresponding to >the two ISO 639-3 designations. In that case, I >suggest omitting the >"Language-Type" field when the value is "living," and >omitting the >"Scope" field when the value is "individual," since these are >the >overwhelming majority and can be treated as defaults. > >-- >Doug Ewell >* Arvada, Colorado, USA * RFC 4645 * UTN >#14 >http://www.ewellic.org >http://www1.ietf.org/html.charters/ltru-charter.html >http://www.alvestrand.no/mailman/listinfo/ietf-languages > ヒ«>_______________________________________________ >Ltru mailing >list >Ltru at ietf.org >https://www.ietf.org/mailman/listinfo/ltr #-#-# Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:duerst at it.aoyama.ac.jp
_______________________________________________ Ltru mailing list Ltru at ietf.org https://www.ietf.org/mailman/listinfo/ltru
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.