I would prefer to have the name "Germanic languages" only, as is used in 639-5, once 639-5 has been finalized. A Part-2 implementation would have to have these items somehow marked, and the corresponding table would need to have a finite list of items that aren't included.
I think that this will have to be an important part of the maintenance of 639-2 (and other defined subsets of 639) in the future. All this needs to be put into place when 639-5 is finished. I think we can live with an "imperfect" solution in the meantime.
Håvard
----------------------------------------------------
Håvard Hjulstad
Standard Norge / Standards Norway
mailto:[log in to unmask]
----------------------------------------------------
________________________________
Fra: ISO 639 Joint Advisory Committee på vegne av Peter Constable
Sendt: to 2007-12-20 17:08
Til: [log in to unmask]
Emne: Re: decision required: "other" collections
If I understand you correctly, you're saying that Part 2 can continue to use "Germanic (Other)" but that Part 5 and "639 as a database" will use "Germanic". Is that right?
Peter
From: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] On Behalf Of Håvard Hjulstad
Sent: Thursday, December 20, 2007 12:20 AM
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/
--------------------
|