Subject: Re: RE: [Ltru] To invert or not to invert?

From: <[email-masked]>
Date: Mon, 11 Dec 2006 10:59:05 -0000

IMHO the secret is to identify the concept of the object by the most transparent designation and enter that as the preferred entry, if there are likely synonyms they should be allowed for, preferably with links to that preferred designation.
For translations the concept of the object is all that is important to be identified then the same process for applying a suitable designation should apply for THAT language i.e. the most transparent designation for THAT language is chosen as the preferred term plus synonyms etc, i.e. it is not necessarily a literal translation of the original language entry, English or otherwise.
This approach then applies to whatever language the original entries have been written in and maintains a reasonable chance of common understanding of the concept/language in question.
Chris
----- Original Message -----
From: Debbie Garside [mailto:[email-masked]]
To: [email-masked],[email-masked]
Cc: [email-masked]
Sent: Mon, 11 Dec 2006 10:07:58 -0000
Subject: RE: [Ltru] To invert or not to invert?

 Doug wrote:

> Then what you really want is a Reference-Description:

Yes! You (LTRU) really must read the standard and use a Reference Name
(Description).

As to inverted or non-inverted. Have both.  But mirror the ISO 639-3 file
other than when there is a perceived need for adding additional inverted
forms.

BTW, IMHO there is a marked difference between "Church Slavonic" and "Old
Church Slavonic"; two separate entities.

Debbie

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 11 Dec 2006 06:12:25 -0800

Debbie Garside wrote;

>>> In all cases, we should verify that comma outside of parens *only* 
>>> occurs in the case of inversion.
>>
>>That has already been done by the Official Doug.
>
> This is a rule that is now set within ISO 639-3.

But something we still need to verify in the names that come from 639-2.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: John Cowan <[email-masked]>
Date: Mon, 11 Dec 2006 10:33:21 -0500

> Church Slavonic"; two separate entities.

Yes and no.  The distinction is analogous to the difference between
Mediaeval and Classical Latin.  In both cases we have a literary
language based on an archaic version of the spoken language, with some
accommodations to the vernacular next to which it is used.  As time
goes on, the adaptations grow larger and more diverse as the vernacular
forms split into separate languages (eventually with their own literary
traditions), new vocabulary is added, and the especially archaic features
of the old standard are dropped, first in phonology, then in morphosyntax.

But in both cases the changes are slow and gradual, and do not amount to
a change of language according to the ISO 639-3 definitions.  RFC 4646
variants is probably the right level, if anyone needs to make the
distinction.

-- 
On the Semantic Web, it's too hard to prove     John Cowan    [email-masked]
you're not a dog.  --Bill de hOra               http://www.ccil.org/~cowan

---

From: Addison Phillips <[email-masked]>
Date: Mon, 11 Dec 2006 09:39:44 -0800

I oppose adding more new fields. Especially I oppose adding pointless 
new fields. Description is a good enough receptacle for descriptions 
taken from ISO 639. Note that RFC 4646 takes the descriptions directly 
from ISO 639 and so does RFC 4646bis.

If you want the descriptions to exactly match ISO 639's text, propose 
text for RFC 4645bis to say that is the policy.

I think the use of SHOULD in RFC 4646bis is appropriate. If a 
misspelling occurs or ISO 639 were to adopt some funky formatting in a 
particular entry, the option to modify it remains.

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.

Internationalization is an architecture.
It is not a feature.

---

From: Peter Constable <[email-masked]>
Date: Mon, 11 Dec 2006 17:56:23 -0800

Perhaps I'm wrong, but I'm wondering if, in this debate we have failed to do the most important thing: review what purpose(s) we intend descriptions to serve.
 
In general terms, I think the descriptions can serve one of two purposes for a user of the registry:
 
(1) Given a particular ID, determine what concept (a language variety) it is identifying.
 
(2) Given a particular concept (a language variety, known to the user by some name), determine what the appropriate ID is.

Now, for (1), we can always point the user to the source standard, ISO 639; indeed, I think that's were the user ought to be going to clarify any questions that they may have about what those IDs denote. (Of course, as always I'm assuming that ISO 639 is doing a good job of documenting that.) For this purpose, the description is mainly useful as a second cue to help the user be sure that they find the right item when they look at the source standard (e.g. the error rate looking up "svx" is bound to be higher than the error rate lookup up "svx, 'Skalvian'"). 
 
For (1), inverted names serve no particular purpose. 
 
(In fact, if users are directed to the source standard, I don't see any reason for needing anything beyond a reference name.)

For (2), an inverted name can be of use. But for this purpose one really needs every different name and every different spelling of a name in common use, including names in the indigenous language itself as well as other languages, and including whatever writing system (including transliterations) may be used for one of these names. The very fact that we list only the English names from 639-1/-2 makes clear that we are not attempting to support this purpose to a very great extent.
 
*If we are intended to support purpose (2) at all, we only support it to a limited extent.*
 
We should clarify for ourselves just how much our intent is to support purpose (2); and in light of our answer, we should evaluate how much benefit is provided if we include an inverted name, a non-inverted name, or both.
 
For my part, I think if I were looking for Old Church Slavonic in this registry and were wanting to base my search on "Slavonic", then probably I'd be viewing the registry in a plain-text viewer and would search on "Slavonic" - and I'd find it whichever way it was listed in the registry. 
 
If some application developer wants to offer users alternatives for searching by names, then an application developer can do that - but I think it *isn't* a purpose of the registry to provide them with all those different forms, just as we decided a long time ago that it isn't a purpose of the registry to provide display names in various languages that an application developer might want to use in their UI.

Peter Constable

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 11 Dec 2006 23:16:48 -0800

Debbie Garside <debbie at ictmarketing dot co dot uk> wrote:

> Being a woman, it is my prerogative to change my mind, I believe.

Personally, I think it should be anyone's prerogative to change their 
mind, especially when new information comes to light or upon further 
reflection.  That is how knowledge grows.

There are some folks who mistake stubbornness for strength, and an open 
mind for a weak will, and the result is not good.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 11 Dec 2006 23:21:42 -0800

I wrote:

> There are 2 six-word names, 12 five-word names, 98 four-word names, 
> and 504 three-word names.  That's a lot of pointless repetition.  And 
> that doesn't even count hyphens.

Sorry, I double-counted some.  There are 2 six-word names, 10 five-word 
names, 86 four-word names, and 406 three-word names, for a total of 504. 
That's still a lot of pointless repetition.