'car' in different ISO 639 parts

I'm in the process of building a new 4645bis Registry that takes into 
account the ISO 639-5 data, which I assume I have the rights to use.

Generally, when two different parts of ISO 639 apply different names to 
the same code element, we have a policy of keeping all the names in the 
Registry, because it was considered important for traceability.  So we 
will have things like:

Type: language
Subtag: ms
Description: Malay (macrolanguage)
Description: Malay
Added: 2005-10-16
Suppress-Script: Latn

because ISO 639-2 calls it simply "Malay" while ISO 639-3, which has to 
differentiate macrolanguage codes from individual language codes, calls 
it "Malay (macrolanguage)".  This doesn't pose a problem since the 
different names seem to refer to the same linguistic concept.

Now, ISO 639-5 draws a formal distinction between "language groups" and 
"remainder groups," concepts used in (but not formally defined by) ISO 
639-2.  These are identified primarily by the words "languages" or 
"(Other)" in the ISO 639-2 name.  A code element like 'apa' ("Apache 
languages") is considered to cover all Apache languages, whereas a code 
element like 'gem' ("Germanic (Other)") covers only those Germanic 
languages that do not have an ISO 639-2 code element of their own.  Both 
the LTRU WG and ietf-languages are familiar with this concept and have 
discussed it often.

Re: [Ltru] 'car' in different ISO 639 parts

John Cowan <cowan at ccil dot org> wrote:

> I bugged the Library of Congress (which is both 639-2/RA and 639-5/RA) 
> about this one; in the end, only they can decide.

So there is no way to resolve this in draft-4645bis until the Library of 
Congress reaches a decision?

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

Re: [Ltru] 'car' in different ISO 639 parts

Doug Ewell scripsit:

> For 'car' we have a unique problem.  ISO 639-5 defines this code element 
> as "Carib languages" and calls it a group (not remainder) code, but ISO 
> 639-2 and 639-3 both define it as "Galibi Carib".  This was officially 
> changed in 639-2 from plain "Carib" on 2006-11-22.  Indeed, 639-3 
> identifies this as an Individual language.  This affects not only the 
> Description fields in the Registry, but also the Scope field if it is 
> ultimately decided to add one.

I bugged the Library of Congress (which is both 639-2/RA and 639-5/RA)
about this one; in the end, only they can decide.

--

-- 
Mark Twain on Cecil Rhodes:                    John Cowan
I admire him, I freely admit it,               http://www.ccil.org/~cowan
and when his time comes I shall                cowan <at> ccil.org
buy a piece of the rope for a keepsake.

Re: [Ltru] 'car' in different ISO 639 parts

Doug Ewell scripsit:

> >I bugged the Library of Congress (which is both 639-2/RA and 639-5/RA) 
> >about this one; in the end, only they can decide.
> 
> So there is no way to resolve this in draft-4645bis until the Library of 
> Congress reaches a decision?

*shrug*

I assume that the resolution will be to add a new 3-letter code element
for "Carib languages" and retire the old.

If they don't do so in time, clearly the -2/-3 name has to win, simply
because it has priority.  I suspect what happened was that the 639-5
working group simply missed the reassignment.

--

-- 
Eric Raymond is the Margaret Mead               John Cowan
of the Open Source movement.                    cowan <at> ccil.org
        --Bruce Perens,                         http://www.ccil.org/~cowan
          some years ago

Re: 'car' in different ISO 639 parts

Doug Ewell wrote:

> We need to decide which Description, and by extension which
> scope, should be reflected in the Registry for 'car'.  I ask
> for the guidance of both the LTRU WG and ietf-languages list,
> since this is not only a draft issue but also a registration
> issue, and for that reason I have cross-posted both lists.

>From a non-LTRU POV, let 4646bis decide what to do in 4645bis.
Is ISO 639-5 something I can look up on the Web, does it have
an URL not leading to a "pay for PDF" page ?  

So far ISO 639-2 "frs" vs. 639-3 "stq" is interesting enough,
adding more sources to the mix would increase the number of
sources for potential confusion.  Ideally the various branches
of ISO 639 should sort it out before it hits the review list.

 Frank

Re: 'car' in different ISO 639 parts

Frank Ellermann scripsit:

> Is ISO 639-5 something I can look up on the Web, does it have
> an URL not leading to a "pay for PDF" page ?  

Not yet, but it is expected to become so soon.

> So far ISO 639-2 "frs" vs. 639-3 "stq" is interesting enough,
> adding more sources to the mix would increase the number of
> sources for potential confusion.  Ideally the various branches
> of ISO 639 should sort it out before it hits the review list.

Ideally.  I feel confident that this is a mere oversight that
the RA/JAC will soon sort out.  That's why the JAC exists.

--

-- 
Even the best of friends cannot                 John Cowan
attend each others' funeral.                    cowan <at> ccil.org
        --Kehlog Albran, The Profit             http://www.ccil.org/~cowan

Re: [Ltru] 'car' in different ISO 639 parts

Peter Constable scripsit:

> This is an inconsistency in ISO 639 that the JAC should resolve: 639-5
> is giving a very different denotation from -2/-3 -- a collection scope
> versus individual-language scope -- which is something that should
> never happen.

It would be good if the JAC could expedite this.

Does the provision for "rest groups" in 639-5 and their treatment as
full families mean that the effort to remove "(Other)" in 639-2 is a
dead letter now?

--

-- 
John Cowan  cowan <at> ccil.org  http://www.ccil.org/~cowan
Does anybody want any flotsam? / I've gotsam.
Does anybody want any jetsam? / I can getsam.
        --Ogden Nash, No Doctors Today, Thank You

RE: [Ltru] 'car' in different ISO 639 parts

> From: ltru-bounces <at> ietf.org [mailto:ltru-bounces <at> ietf.org] On Behalf Of
> Doug Ewell


> For 'car' we have a unique problem.  ISO 639-5 defines this code
> element
> as "Carib languages" and calls it a group (not remainder) code, but ISO
> 639-2 and 639-3 both define it as "Galibi Carib".

This is an inconsistency in ISO 639 that the JAC should resolve: 639-5 is giving a very different denotation
from -2/-3 -- a collection scope versus individual-language scope -- which is something that should
never happen.



Peter

_______________________________________________
Ietf-languages mailing list
Ietf-languages <at> alvestrand.no
http://www.alvestrand.no/mailman/listinfo/ietf-languages

RE: [Ltru] 'car' in different ISO 639 parts

> From: John Cowan [mailto:cowan <at> ccil.org]

> > This is an inconsistency in ISO 639 that the JAC should resolve: 639-
> 5
> > is giving a very different denotation from -2/-3 -- a collection
> scope
> > versus individual-language scope -- which is something that should
> > never happen.
>
> It would be good if the JAC could expedite this.

I have raised the issue.

> Does the provision for "rest groups" in 639-5 and their treatment as
> full families mean that the effort to remove "(Other)" in 639-2 is a
> dead letter now?

I'm guessing it might.

Peter

[Ltru] 'car' in different ISO 639 parts

Hi, would the following clause require JAC to expedite its decision as to whether car refers to a single
language or not??  
According to:

http://www.loc.gov/standards/iso639-2/annexa.html

"A.3.3 Additions and deletions to the list of entities, changes of codes
Requests for additions, deletions, and changes of codes shall be supported by a justification. When ISO
639-2/RA consults ISO 639/RA-JAC about the proposed inclusion, deletion or change, and suggests a code,
ISO 639/RA-JAC is obliged to respond within one month. Simultaneously ISO 639-1/RA will be informed and
asked for comments."

--C. E. Whitehead
cewcathar <at> hotmail.com

Peter Constable petercon at microsoft.com
Mon Jun 9 19:47:09 CEST 2008

> From: John Cowan [mailto:cowan at ccil.org]

>>> This is an inconsistency in ISO 639 that the JAC should resolve: 639-
>>> 5
>>> is giving a very different denotation from -2/-3 -- a collection
>>> scope
>>> versus individual-language scope -- which is something that should
>>> never happen.

>> It would be good if the JAC could expedite this.