Peter,
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.
-Joan
Peter Constable <[log in to unmask]>
Sent by: ISO 639 Joint Advisory Committee <[log in to unmask]>
2008-01-16 05:08 PM
Please respond to
ISO 639 Joint Advisory Committee <[log in to unmask]>
To
[log in to unmask]
cc
Subject
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.
-Joan
Peter Constable <[log in to unmask]>
Sent by: ISO 639 Joint Advisory Committee <[log in to unmask]>
2008-01-16 10:43 AM
Please respond to
ISO 639 Joint Advisory Committee <[log in to unmask]>
To
[log in to unmask]
cc
Subject
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]
