Print

Print


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/ 
--------------------