> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On Behalf Of > Doug Ewell > Should we consider incorporating the 639-5 code elements into > draft-4645bis? Well, here's an interesting reason for saying that we should: We have discussed before concerns over inherent *in*stability of the "(other)" collections in ISO 639-2: if any member language is coded, then the denotation of the ID for that collection has narrowed, and some unknown number of existing usages become incorrectly tagged. For that reason, I was trying to get agreement within the JAC to change all the exclusive "(other)" collections to regular, inclusive collections. I thought I had obtained a consensus agreement, although the librarians really wanted to continue using the exclusively-defined categories -- I was trying to get agreement to treat that as an implementation decision. Well, it turns out that 639-5 has baked in an interesting relationship with 639-2 in relation to these "(other)" collections: the categories are part of both codes (indeed, all collections in -2 are in -5), and they denote the same groupings *with the exception* that they are *exclusive* collections in -2 but are *inclusive* in -5. Here's a quotation from clause 3.2 of ISO/FDIS 639-5: <quote> There are currently 55 items that are included both in ISO 639-2 and in ISO 639-5. Of these items, 20 items are identical in the two parts (e.g. “alg – Algonquian languages”). The remaining 35 items are intended to cover remainder groups in ISO 639-2 and entire language groups in ISO 639-5 (e.g. “afa – Afro-Asiatic (Other)” in ISO 639-2 and “afa – Afro- Asiatic languages” in ISO 639-5). </quote> Thus, if we want to get rid of exclusive collections, it looks like we should probably reference 639-5. Between 639-5 and 639-3, it looks like 639-2 would be redundant for our purposes. Peter _______________________________________________ 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.