I think you mistook my intent. I said
that I see your point. By that, I mean you are right to point out that
the mapping does not change. Your first email caused me to think about
the issue. In my suggestion, I am not introducing a new property, I am
merely wanting to assist users to see that mappings include retired code
elements, specifically on the side of the individual language. (I think
the retirement of a whole macrolanguage, or a change in scope from M to
I, as happened with Occitan (post 1500) [oci] should remove its macrolanguage
mapping, as in that case, all its member individual languages were also
retired and merged into [oci].)
To do this, I propose the following
(a new column in the Macrolanguage Mappings table):
CREATE TABLE ISO_639-3_Macrolanguages
(
M_Id char(3) NOT NULL, -- The identifier
for a macrolanguage
I_Id char(3) NOT NULL, -- The identifier
for an individual language
-- that is a member of the macrolanguage
I_Status
char(1) NOT NULL) -- A (adopted) or R (retired) indicating
the
-- status of the individual code element
I think this is necessary because the
retired code elements are not in the main ISO 639-3 code set table, but
are instead listed in the Retired Code Element Mappings table. (This has
been so since before the first official release in Feb 2007). The I_Status
above is the same property that distinguishes whether a code element is
listed in the main table or the retired code elements table; it adds no
new information, but it signals in this table to which other table the
link must be made for the denotation of the code element.
Re: The 2007 round of changes for Part
3 have been decided
The macrolanguage-mapping
property that an ID has and the status property that it has are two distinct
– and combinable – properties. There’s no reason to introduce a separate
macrolanguage-mapping-for-retired-IDs property. If a customer uses macrolanguage-mapping
information to recognize that connection between two IDs, they should still
be able to recognize that connection if they encounter the deprecated ID
in the future, and there’s no reason why they shouldn’t be able to do
this with the very same data tables.
The semantic of ccx has not
changed as a result of it being “retired” – keep in mind that “retired”
means nothing more than “no longer recommended”. Because the semantic
hasn’t changed, the relationship between that semantic and the semantic
of zha also has not changed.
I’m very surprised at and
concerned about this change.
Peter
From: ISO 639 Joint Advisory Committee
[mailto:[log in to unmask]] On Behalf Of Joan Spanne
Sent: Wednesday, January 16, 2008 10:31 AM
To:[log in to unmask]
Subject: Re: The 2007 round of changes for Part 3 have been decided
I understand your point, Peter. However, I think retired code elements
that have been included in macrolanguage groups should be handled separately,
or at least in distinction from current mappings. They may require a separate
table, or alternatively, an indication of retired status in the one mapping
table.
Re: The 2007 round of changes for Part 3
have been decided
Joan: you removed the macrolanguage mapping from cxx (Northern Zhuang)
to zha (Zhuang), evidently because cxx has been retired. I would not have
thought that retiring an ID causes the macrolanguage mapping to go away.
If there are existing uses of cxx and zha, those should not be affected
apart from a recommendation to transition from using cxx to other, more
granularly-divided IDs. This represents a stability problem: we don’t
want to make changes that can invalidate existing usage.
In general, I’m inclined to think that macrolanguage mappings should rarely
if ever be removed once defined.
Peter
From: ISO 639 Joint Advisory Committee [mailto:[log in to unmask]] On
Behalf Of Joan Spanne
Sent: Wednesday, January 16, 2008 7:49 AM
To:[log in to unmask]
Subject: The 2007 round of changes for Part 3 have been decided
Dear JAC,
The decisions for most of the 258 change requests submitted for the 2007
round have been finalized, and are summarized in the attached report. The
same report is posted on the home page of the 639-3 site. There are 10
remaining requests that are not yet decided, one of which relates to a
ISO 639-2 code element (was being considered as a macrolanguage possibility),
another which should probably be considered by the whole JAC. For the other
eight, I would appreciate the input of members of the JAC, as well. For
some of them, I have additional research information, which I will forward
in separate memos.
All the requests still pending can be seen at:
http://www.sil.org/iso639-3/chg_requests.asp
(you will see that there is still the matter of Medieval Greek still pending;
I will revive discussion on that shortly, once "other" collections
is finished)
Thanks,
Joan Spanne
ISO 639-3/RA
SIL International
7500 W Camp Wisdom Rd
Dallas, TX 75236 [log in to unmask]
