Subject: Re: [Ltru] 639-5 (was RE: ISO 639 language code addition rules...)

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 12:45:12 -0600

Peter Constable <petercon at microsoft dot com> wrote (sorry for the 
length of quotational material):

>> But I would like some firmer recording in the LSR of the fact that a 
>> code is a collection/family code (rather than relying on "languages" 
>> or "(family)" being part of the name, or just referring back to 
>> 639-5). Something like "Type: language collection" or similar. 
>> Pushing this a bit, macrolanguages should similarly be explicitly 
>> recorded as such (rather than just implicitly), by something like 
>> "Type: macrolanguage" instead of just "Type: language". I know there 
>> is a way of inferring this information, but it is better to be 
>> explicit, and not need to infer that information or refer back to 
>> the -3 registry. IIUC, this would leave "Type: language" for 
>> individual languages only.
>
> If this sounds a bit familiar, we did discuss this back in ancient 
> times -- Nov 2006. The 639-3 code tables were first getting checked 
> out, and Mark Davis commented on what he thought should be included or 
> excluded in the LSTR. The scope attribute (which is the one you're 
> mentioning) is one that Mark thought wasn't needed since it could be 
> derived. John Cowan concurred. Randy mentioned feature creep in 
> relation to some other info, but didn't make a clear link between that 
> comment and the scope attribute. Doug made mixed comments: he agreed 
> that scope was derivable hence not needed, but also suggested adding 
> _collection_ to Type information. But then we got sidetracked onto 
> Swiss German. I' haven't seen if we ever decided against that or just 
> forgot about it.

If I remember correctly, what I suggested was to add a "Scope" field to 
the Registry that would reflect both the Scope and Language_Type fields 
in the ISO 639-3 database.  This would be something like "macrolanguage" 
for macrolanguages, "special" for things like 'mis' and 'mul', 
"collection" for collection codes, and other terms like "extinct" and 
"constructed" and "historic" as indicated by 639-3.  The most common 
scope/type combination by far ("individual, living") would be indicated 
by the absence of a Scope field.  All of this would be strictly tied to 
ISO 639-3, would use 639-3 terminology, and would be changed whenever 
the RA changed it; and it would be very, very informative.

This was in the days when it was assumed and expected that we would have 
extlang, and "Scope: macrolanguage" was expected to be strictly 
informative since ISO 639-3 could change the macrolanguage groupings at 
any time (as they have indeed done).

At the time, this idea was criticized for conflating two separate ISO 
639-3 concepts (which it did, but I didn't see this as a problem) and 
for adding unnecessary encyclopedic information to the Registry (which 
seems to be what some people want after all, as Kent's comment shows). 
I still think it has advantages, except that if we have:

    Subtag: bs
    Macrolanguage: sh

there seems little point in also having:

    Subtag: sh
    Scope: macrolanguage

although I know some people like this "doubly-linked list" approach.

--
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
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Kent Karlsson" <[email-masked]>
Date: Mon, 2 Jun 2008 00:00:00 +0200

Doug Ewell wrote:
> scope/type combination by far ("individual, living") would be 
> indicated by the absence of a Scope field.  All of this would be 
> strictly tied to ISO 639-3, ...

Well, as others noted (and I forgot about) there are some "special"
codes from ISO 639-2 which do not occur in -3 and maybe not -5 either
(not sure about the latter). And collection codes would be tied to
-5 (rather than -2, assuming we concur to adopt -5) since they do not
occur in -3. So not all of that can be strictly tied to -3.

	/kent k

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 22:46:51 -0600

Kent Karlsson <kent dot karlsson14 at comhem dot se> wrote:

> (not sure about the latter). And collection codes would be tied to -5 
> (rather than -2, assuming we concur to adopt -5) since they do not 

I hadn't realized, although it makes sense in retrospect, that 639-5 
doesn't have the special codes that 639-2 has (especially since I don't 
have a copy of 639-5).  So yes, we will still need to reference -2 as 
well as -3 and -5, assuming that my suggestion to incorporate the -5 
codes is adopted (I haven't seen any major opposition yet, but then it 
is the weekend).

---

From: Peter Constable <[email-masked]>
Date: Sun, 1 Jun 2008 22:06:16 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Doug Ewell

> well as -3 and -5

Look at the data file from 639-3: the special-purpose categories are in 639-3.

Peter

---

From: "Doug Ewell" <[email-masked]>
Date: Sun, 1 Jun 2008 23:11:32 -0600

> Look at the data file from 639-3: the special-purpose categories are 

Sigh.  You are right, of course.  I complained just yesterday about 
'zxx' not having the same names in 639-2 and 639-3.

Are there any other cases where we would need to reference 639-2, or is 
everything covered by 639-1, 639-3, and 639-5?