 |
 |
For the sake of precision a remainder group should have all the exclusions clearly stated (together with the date of adding an inclusion), such as: Germanic languages, other than xxx 2001-03-03, yyy 2003-04-01, zzz 2004-02-19, etc. I agree with Håvard and I am looking forward to "639 as database" with a very clear mechanism showing which sub-items are covered by "xxx other than..." as a remainder group + date of addition/deletion of languages reflecting the gradual change of the remainder group over time. Best regards Christian ________________________________________ From: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] On Behalf Of Håvard Hjulstad Sent: Donnerstag, 20. Dezember 2007 09:20 To: [log in to unmask] Subject: Re: decision required: "other" collections I have with interest followed the discussion relating to "remainder groups". The issue is actually discussed in Part 5, which will soon be finalized. The definition is as follows: 2.7 remainder group language group (2.6) with the explicit exclusion of specified languages NOTE 1 In ISO 639-2, a typical example of a remainder group is “gem” = “Germanic (other)”, which has the extension of all languages and language groups belonging to the Germanic language family with the exception of all individual languages and language groups within that family that have separate identifiers in ISO 639-2. The issue is also discussed in Part 4, which identifies this as an implementational issue, not an issue relating to defining linguistic entities. It became quite clear early in the Part 3 development process that this needed to be sorted out. That is the background for the wording in Part 5 (and Part 4). Depending on how many, e.g., individual Germanic language that an implementation uses, the value of "gem" will be different. In fact, "gem" can only have a stable meaning in implementations that just uses "gem" as meaning "Germanic languages"; in all other cases "gem" will mean "the Germanic languages that we in this implementation have decided not to encode in more detail, which may change tomorrow". Part 2 is the only stable subset of the 639 alpha-3 code (so far defined). For the purpose of Part 2 all "group identifiers" are used to denote "remainder groups" (with the exception of those cases where sub-items of a group has been individually identified). For the purpose of Part 2 the designation "Germanic (other)" still makes sense. For the purpose of the entire 639 it doesn't (or possibly it has a different meaning). This has to be seen as an implementational issue, where Part 2 is an "implementation". And it has to be described properly as such. This needs to be described in Part 4 in a correct and understandable way. The issue cannot be solved by changing the "names" in Part 2. As I see it, the future "639 as database" will have one entry "gem" with the generic name "Germanic languages", a link to a proper description of "language groups and remainder groups", links to all sub-items (regardless of Part 2 or Part 3), and a very clear mechanism to show which sub-items are covered by "gem" as a remainder group for implementations using the defined subset of Part 2. Håvard -------------------- Håvard Hjulstad Standard Norge / Standards Norway Postboks 242, NO-1326 Lysaker besøksadresse / visiting address: Strandveien 18 tel: (+47) 67838600 | faks / fax: (+47) 67838601 direkte tel / direct tel: (+47) 67838645 [log in to unmask] http://www.standard.no/ --------------------