Randy Presuhn | 2 Jul 02:12 2006
Picon

Re: gen-art review and response...

Hi -

> From: "Addison Phillips" <addison <at> yahoo-inc.com>
> To: "'LTRU Working Group'" <ltru <at> ietf.org>
> Cc: <gen-art <at> ietf.org>
< Sent: Friday, June 30, 2006 9:53 AM
> Subject: [Ltru] gen-art review and response...
...
> s2.1, para 3: s/Such ill-formed ranges/Any ranges that are not well-formed/
>
> [Addison] I don't care for this edit.
...

The first ("such ill-formed ranges") only refers to ranges that are ill-formed
in some particular way.  However, in the context in which the phrase appears,
there's nothing to indicate what might be meant by "such", since ill-formed
ranges are not previously discussed in the paragraph.  Though I think the
suggested edit is better, I'd be even happier with a simple "Ranges that are
not well-formed".

Randy

Misha Wolf | 2 Jul 22:37 2006
Picon

RE: New UN code elements for "Serbia" and "Montenegro"

This rule seems to be a candidate for improvement in the 
next batch of work.

Misha


-----Original Message-----
From: ietf-languages-bounces <at> alvestrand.no [mailto:ietf-languages-bounces <at> alvestrand.no] On
Behalf Of Doug Ewell
Sent: 01 July 2006 18:18
To: ietf-languages <at> iana.org
Subject: New UN code elements for "Serbia" and "Montenegro"

The UN Statistics Division has assigned new 3-digit numeric M.49 code 
elements for Serbia (688) and for Montenegro (499), and has listed the 
previously assigned code element for Serbia and Montenegro (891) under 
the heading "Codes not in current use."

References:
http://unstats.un.org/unsd/methods/m49/m49alpha.htm

http://unstats.un.org/unsd/methods/m49/m49chang.htm


The first paragraph of Section 3.3 of draft-registry says that as new 
codes are assigned in (among others) UN M.49, the Reviewer MUST evaluate 
them for inclusion as new subtags in the Registry, and submit them if 
there is no conflict.

However, since it is widely expected that ISO 3166/MA will soon assign 
new alpha-2 (and alpha-3) code elements for these two countries, 
corresponding to these UN code elements, I suggest we do NOT rush to 
(Continue reading)

Doug Ewell | 2 Jul 23:50 2006
Picon
Picon

Re: New UN code elements for "Serbia" and "Montenegro"

Misha Wolf <Misha dot Wolf at reuters dot com> wrote:

> This rule seems to be a candidate for improvement in the next batch of 
> work.

I agree.  The basic premise of ISO 3166 is that they assign alphabetic 
code elements that correspond to UN numeric code elements.  In other 
words, it is expected that UN will change their code list before ISO 
does.  We prefer to assign region subtags based on ISO code elements 
rather than UN, yet Section 3.1 says the Reviewer is supposed to act 
upon changes to the UN code list just like the others.

I suggest the process should be something like this: when an addition is 
made to the UN list of countries and country-like entities. the Reviewer 
(with assistance as necessary) should investigate whether ISO 3166/MA 
plans to assign a corresponding alpha-2 code element, and if so, should 
NOT automatically add a subtag based on the UN code element, but should 
wait (for a period not to exceed N months) until ISO does its job.

The value N may be subject to some discussion.  Apparently 6 months is 
not uncommon, and the ISO code elements for Guernsey, Jersey, and Isle 
of Man reportedly took 8 months after being proposed because they went 
to a second vote.  (Of course, this does not count the time during which 
the numeric UN codes existed but ISO did not add corresponding alpha 
codes, as they say they do.)

I would certainly hope ISO would not take 6 or more months to assign 
code elements for Serbia and for Montenegro, but even if they do, it 
would still be better to wait for "SP" and "ME" (or whatever the ISO 
code elements will be) than to assign region subtags "688" for Serbia 
(Continue reading)

Misha Wolf | 2 Jul 23:59 2006
Picon

RE: New UN code elements for "Serbia" and "Montenegro"

Doug wrote:

> I suggest the process should be something like this: 
> when an addition is made to the UN list of countries and 
> country-like entities [...]

I agree, though the length of the waiting period for country 
alpha codes must be to some extent discretionary as we would 
not want some drawn out tussle between, eg, ISO and Serbia, 
to cause us to make the wrong allocation.

Misha


To find out more about Reuters visit www.about.reuters.com


Any views expressed in this message are those of the individual sender, except where the sender
specifically states them to be the views of Reuters Ltd.

Doug wrote:

> I suggest the process should be something like this: 
> when an addition is made to the UN list of countries and 
> country-like entities [...]

I agree, though the length of the waiting period for country 
alpha codes must be to some extent discretionary as we would 
not want some drawn out tussle between, eg, ISO and Serbia, 
(Continue reading)

Brian E Carpenter | 3 Jul 10:06 2006
Picon

Re: Gen-art review of draft-matching (Brian's comments)

Actually the question was based on my slight misunderstanding of Elwyn's
review comments. But I take it that you're saying the WG really meant
what it wrote, which is the point.

 > ...the WG discovered that none of the algorithms we ended up with
 > in this document needed such a syntax. Therefore we didn't document one.

It's possible that a sentence to this effect would prevent future
readers asking themselves Elwyn's question, but I won't insist.

     Brian

Addison Phillips wrote:
> Brian Carpenter asked Mark and I privately:
> 
> --
> I'd really like to have the authors' and shepherds' comments
> on section 2.2 before casting my ballot on this. Did the WG consciously
> decide that en-*-*-*-en was valid, and distinct from
> en-*-*-en? 
> --
> 
> en-*-*-*-en is not functionally distinct from "en-*-*-en" (or en-*-en, en-en, or en-en-*, for that matter).
> 
> It is possible to construct a language range syntax that uses RFC 3066bis's syntax. In such a syntax the
position and number of wildcards would be significant. However, the WG discovered that none of the
algorithms we ended up with in this document needed such a syntax. Therefore we didn't document one.
> 
> Addison
> 
(Continue reading)

McDonald, Ira | 3 Jul 17:40 2006

RE: gen-art review and response...

+1

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald <at> sharplabs.com

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com]
> Sent: Saturday, July 01, 2006 8:13 PM
> To: LTRU Working Group
> Subject: Re: [Ltru] gen-art review and response...
> 
> 
> Hi -
> 
> > From: "Addison Phillips" <addison <at> yahoo-inc.com>
> > To: "'LTRU Working Group'" <ltru <at> ietf.org>
> > Cc: <gen-art <at> ietf.org>
> < Sent: Friday, June 30, 2006 9:53 AM
> > Subject: [Ltru] gen-art review and response...
> ...
> > s2.1, para 3: s/Such ill-formed ranges/Any ranges that are 
> not well-formed/
> >
> > [Addison] I don't care for this edit.
> ...
> 
> The first ("such ill-formed ranges") only refers to ranges 
(Continue reading)

Randy Presuhn | 4 Jul 03:25 2006
Picon

Re: DISCUSS: draft-ietf-ltru-matching

Hi -

> From: "Brian Carpenter" <brc <at> zurich.ibm.com>
> To: <iesg <at> ietf.org>
> Cc: <ltru-chairs <at> tools.ietf.org>
> Sent: Monday, July 03, 2006 1:11 AM
> Subject: DISCUSS: draft-ietf-ltru-matching 
>
> Discuss:
> (from Gen-ART review by Elwyn Davies)
> 
> Assuming we are supposed to be using RFC4234 conventions throughout:
> s2, para 3: s/%2A/%x2A/
> s3.3.2, para 2 (Item 1.): s/%2D/%x2D/
> 

The need for this correction has already been noted (on June 30) on the
ltru WG mailing list in response to Elwyn's comments.  No one has
disagreed.  Our AD (Ted) has indicated that an RFC editor note would
be sufficient for making this correction before publication.

Randy

Brian E Carpenter | 4 Jul 09:25 2006
Picon

Re: DISCUSS: draft-ietf-ltru-matching

Sure, Randy, I will clear my DISCUSS when the RFC Editor note is in the tracker.

    Brian

Randy Presuhn wrote:
> Hi -
> 
> 
>>From: "Brian Carpenter" <brc <at> zurich.ibm.com>
>>To: <iesg <at> ietf.org>
>>Cc: <ltru-chairs <at> tools.ietf.org>
>>Sent: Monday, July 03, 2006 1:11 AM
>>Subject: DISCUSS: draft-ietf-ltru-matching 
>>
>>Discuss:
>>(from Gen-ART review by Elwyn Davies)
>>
>>Assuming we are supposed to be using RFC4234 conventions throughout:
>>s2, para 3: s/%2A/%x2A/
>>s3.3.2, para 2 (Item 1.): s/%2D/%x2D/
>>
> 
> 
> The need for this correction has already been noted (on June 30) on the
> ltru WG mailing list in response to Elwyn's comments.  No one has
> disagreed.  Our AD (Ted) has indicated that an RFC editor note would
> be sufficient for making this correction before publication.
> 
> Randy
> 
(Continue reading)

Karen_Broome | 6 Jul 00:18 2006
Picon

Fw: Preliminary Investigation into Application of ISO 11179


Yes, Debbie. I'm looking at  ISO 11179 right now internally and with other external projects.  It's in my best interest to look at its application from as many angles as possible.

Happy to help, as you I think you know....

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384


"Debbie Garside" <debbie <at> ictmarketing.co.uk>

06/30/2006 12:42 PM

To
"'Debbie Garside'" <debbie <at> ictmarketing.co.uk>, <Karen_Broome <at> spe.sony.com>
cc
"'Doug Ewell'" <dewell <at> adelphia.net>, "'LTRU Working Group'" <ltru <at> ietf.org>
Subject
RE: [Ltru] Preliminary Investigation into Application of ISO 11179





Hi Karen
 
I have looked at this in a little more detail now and you are correct if we were to consider "Strictly Conforming" to ISO 11179.
 
However, having completed a preliminary test map from the Registry (and associated documentation within the RFC) to Clause 5 of part 3 (Basic Attributes) as well as the requirements of part 6 (as outlined in my previous mail), I think Conformance Level 1 (part 3 clause 6) could be achieved without too much effort.
 
That said, I would really want to study this in more detail, my investigations are still very much preliminary -  I would like to do a true implementation to be absolutely sure.
 
If the WG decide to put investigation of implications and benefits of conformity with ISO 11179 for the Registry within the new Charter I would be happy to work with you on this if you have time.
 
Best regards
 
Debbie Garside

From: Debbie Garside [mailto:debbie <at> ictmarketing.co.uk]
Sent: 28 June 2006 08:44
To: Karen_Broome <at> spe.sony.com
Cc: 'Doug Ewell'; 'LTRU Working Group'
Subject: RE: [Ltru] Preliminary Investigation into Application of ISO 11179

Hi Karen
 
Thanks for your input.  I need to do a little more reading before I respond so it may be a few days :-)
 
I think there are two ways of looking at 11179: 1. As a standard to assist in the design of a Meta-data Registry 2. As a standard to apply to an existing Meta-Data registry.
 
I have been looking at what is as a bare minimum absolutely necessary in order to apply ISO 11179 to the LTRU Registry.  I have read the whole standard but I need to do further depth reading to see what is required for the Registry to be conformant.
 
There are one or two things that you have mentioned that do not fit with my interpretation but I would not want to say more until I have studied it further.
 
best regards
 
Debbie
 

From: Karen_Broome <at> spe.sony.com [mailto:Karen_Broome <at> spe.sony.com]
Sent: 28 June 2006 01:06
To: Debbie Garside
Cc: 'Doug Ewell'; 'LTRU Working Group'
Subject: Re: [Ltru] Preliminary Investigation into Application of ISO 11179


Debbie,

Did you review all of ISO 11179 or just 11179-6?

There is a lot more to ISO 11179 than just the administrative practices (-6) and the previous parts discuss a hierarchical metadata model not mentioned in your review below. I think you're confusing the terms "value" and "representation" and the other sections provide clarity on this.  The top of the hierarchy is the Data Concept, which is an abstract description independent of its representation -- a pure semantic layer.

The hierarchy, as I understand it, would be something like this:

Data Concept
       Language Code: A standardized code used to identify a particular language or dialect.

Data Elements [Data Concept + Representation Class] related to "Language Code" data concept =
1.        ISO 639-1 Language Code:  A two-letter code assigned by the ISO 639-1 standard to identify a particular language.
2.        ISO 639-2/B Language Code
3.        ISO 639-2/T Language Code
4.        ISO 639-3 Language Code
5.        ISO 639-6 Language Code

Value Domain
       Each data element in this case has a "Value Domain" and the Value Domain contains the individual values such as "en-US".

...

For the Language Code data concept, the ISO 11179 structure seems relevant and useful. But when we look at some of the other concepts, it seems less useful and perhaps problematic:

Data Concept = Script Code
Data Element = ISO 15924 Script Code

Data Concept = Country Code
Data Element = ISO 3166 Country Code

Note that "Description" or even "Subtag Description" is too vague by ISO 11179 rules (subjective judgment, but there are a lot of examples that support this view) and I think you would need to break these out as:
1.        En-US Language Name
2.        Fr-FR Language Name
3.        En-US Script Name
4.        En-US Country Name
etc.

These are unique data elements relating to several data concepts, so the current model with its "Description" field would need serious revision to be compliant, I think.

I'm not opposed to further discussion of this moving forward. I only question how valuable this is for a standard that has so few data elements. It is a good thing that you're familiar with the section of the standard I've spent the least time reviewing.  :)

Best regards,

Karen Broome
Sony Pictures Entertainment


"Debbie Garside" <debbie <at> ictmarketing.co.uk>

06/27/2006 01:22 AM


To
"'LTRU Working Group'" <ltru <at> ietf.org>
cc
'Doug Ewell' <dewell <at> adelphia.net>
Subject
[Ltru] Preliminary Investigation into Application of ISO 11179







Findings of a preliminary investigation into the application of ISO 11179 to
the RFC3066bis Registry

Cost
Initial investigations suggest that ISO 11179 can be applied to the Registry
at a base level for very little cost.  The main cost is in mapping the ISO
11179 terminology to the existing Registry terminology and a number of
additional data elements would be required.  The Registry already
incorporates a system of metadata elements that are consistent with the
model presented within ISO 11179.  

In particular the value of the following aspects of ISO 11179-6 should be
investigated:

Identification
The attributes registration authority identifier (RAI), data identifier
(DI), and version identifier (VI) constitute the international registration
data identifier (IRDI). At least one IRDI is required for an administered
item.

Data identifiers are assigned by a Registration Authority; data identifiers
shall be unique within the domain of a Registration Authority.

Requirements for a Registration Authority, and a discussion of the IRDI,
appear in ISO/IEC 11179-6.

As each Registration Authority may determine its own DI assignment scheme,
there is no guarantee that the DI by itself will uniquely identify an
administered item. For example, if two authorities both use sequential
6-digit numbers, there may be two administered items with the same DI's;
however, the administered items will almost certainly not be the same.

If one administered item appears in two registers, it will have two DI's.
Therefore, both the DI and the RAI are necessary for identification of an
administered item.

If particular attributes of an administered item change, then a new version
of the administered item shall be created and registered. The registrar
shall determine these attributes. In such a case, a VI is required to
complete the unique identification of an administered item.

For further guidance, see ISO/IEC 11179-6.

An IRDI can serve as a key when exchanging data among information systems,
organizations, or other parties who wish to share a specific administered
item, but might not utilize the same names or contexts.

ISO/IEC 11179 does not specify the format or content of a unique DI.

The IETF (or LTRU) would need to apply for an International Code Designator
(ICD) - a four integer code; this coupled with the organization name as well
as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.
The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes as
Registration Authority Identifier which is currently BSI.  

Implications for the LTRU Registry
The DI (or UI - Unique Identifier) cannot be the Subtag as there are already
conflicting Subtags within the registry (e.g. cy/CY).  It is more preferable
that the unique identifier be the chosen language/country/script name
(please note, this is not the preferred name).  This would fit with the
current ISO 639-3, -5 and -6 models and open the Registry to adoption by
meta-data knowledge grids. (I will take a good look at the naming
conventions within ISO 3166-1 at a later date but prior to publication of
FDIS 3166-1).  

Anomalies within ISO naming conventions of standards issued prior to the
adoption of ISO 11179 can be dealt with on a case by case basis via set
rules.  

The Subtag would become a "Representation" with the name being the unique
"Data Identifier". This would involve having a "Primary Description" which
would form the DI.

In reviewing the "Required Metadata Attributes" for a "Preferred Standard"
Status administered item, preliminary investigations reveal no serious
additional requirements other than those already mentioned here. Some
manipulation and interpretation of registry data and standard mandatory
requirements would be required but no difficulties are envisaged. I would
refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34)

Benefits
The ISO 11179 model allows for there being conflicting codes between
different meta-data registries in conformity with ISO 11179; that is part of
the conceptual model.  ("in conformity with" is correct - there are
essential parts of the standard).

In essence, the ISO 11179 meta-model supports linkage to other ISO 11179
conformant meta-data registries thus facilitating data exchange/interchange
whilst giving the LTRU Registry ownership of the data elements contained
therein - they become LTRU elements giving room for manoeuvre should ISO get
it wrong.

This will make language tags more meaningful in the future.  The key word
here is "linkage".  ISO 11179 conformant meta-data registries facilitate the
creation of knowledge grids, grid computing and the semantic web!

Conclusion
At first glance the cost/value ratio favours ISO 11179; there appears to be
very little cost yet the true benefits of future interoperability and data
exchange are unknown.  

It is recommended that further investigation be conducted before application
of ISO 11179 can be discussed at WG level.

Further benefits with regard to data interchange should be explored.

It is further recommended that the "investigation into application of ISO
11179 Meta Data Registries to the Registry and its registration procedures
be conducted by nominated members of the WG with a view to application" be
added to the new LTRU Charter.  

Best regards


Debbie Garside



_______________________________________________
Ltru mailing list
Ltru <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ltru


<div>
<br>Yes, Debbie. I'm looking at &nbsp;ISO
11179 right now internally and with other external projects. &nbsp;It's
in my best interest to look at its application from as many angles as possible.

<br><br>Happy to help, as you I think you know....
<br><br>Regards,
<br><br>Karen Broome<br>
Metadata Systems Designer<br>
Sony Pictures Entertainment<br>
310.244.4384
<br><br><br><table width="100%"><tr valign="top">
<td width="40%">"Debbie Garside"
&lt;debbie <at> ictmarketing.co.uk&gt; 
<p>06/30/2006 12:42 PM
</p>
</td>
<td width="59%">
<table width="100%">
<tr valign="top">
<td>
<div align="right">To</div>
</td>
<td>"'Debbie Garside'" &lt;debbie <at> ictmarketing.co.uk&gt;,
&lt;Karen_Broome <at> spe.sony.com&gt;
</td>
</tr>
<tr valign="top">
<td>
<div align="right">cc</div>
</td>
<td>"'Doug Ewell'" &lt;dewell <at> adelphia.net&gt;,
"'LTRU Working Group'" &lt;ltru <at> ietf.org&gt;
</td>
</tr>
<tr valign="top">
<td>
<div align="right">Subject</div>
</td>
<td>RE: [Ltru] Preliminary Investigation
into Application of ISO 11179</td>
</tr>
</table>
<br><table><tr valign="top">
<td>
</td>
<td></td>
</tr></table>
<br>
</td>
</tr></table>
<br><br><br>Hi Karen
<br>&nbsp;
<br>I have looked at this in a little
more detail now and you are correct if we were to consider "Strictly
Conforming" to ISO 11179.
<br>&nbsp;
<br>However, having completed a preliminary
test map from the Registry (and associated documentation within the RFC)
to Clause 5 of part 3 (Basic Attributes) as well as the requirements of
part 6 (as outlined in my previous mail), I think Conformance Level 1 (part
3 clause 6) could be achieved without too much effort. 
<br>&nbsp;
<br>That said, I would really want
to study this in more detail, my investigations are still very much preliminary
- &nbsp;I would like to do a true implementation to be absolutely sure.
<br>&nbsp;
<br>If the WG decide to put investigation
of implications and benefits of conformity with ISO 11179 for the Registry
within the new Charter I would be happy to work with you on this if you
have time.
<br>&nbsp;
<br>Best regards
<br>&nbsp;
<br>Debbie Garside
<br><br>From: Debbie Garside [mailto:debbie <at> ictmarketing.co.uk]
<br>
Sent: 28 June 2006 08:44<br>
To: Karen_Broome <at> spe.sony.com<br>
Cc: 'Doug Ewell'; 'LTRU Working Group'<br>
Subject: RE: [Ltru] Preliminary Investigation into Application of ISO
11179<br>
<br>Hi Karen
<br>&nbsp;
<br>Thanks for your input. &nbsp;I
need to do a little more reading before I respond so it may be a few days
:-)
<br>&nbsp;
<br>I think there are two ways of
looking at 11179: 1. As a standard to assist in the design of a Meta-data
Registry 2. As a standard to apply to an existing Meta-Data registry.
<br>&nbsp;
<br>I have been looking at what is
as a bare minimum absolutely necessary in order to apply ISO 11179 to the
LTRU Registry. &nbsp;I have read the whole standard but I need to do further
depth reading to see what is required for the Registry to be conformant.
<br>&nbsp;
<br>There are one or two things that
you have mentioned that do not fit with my interpretation but I would not
want to say more until I have studied it further.
<br>&nbsp;
<br>best regards
<br>&nbsp;
<br>Debbie
<br>&nbsp;
<br><br>From: Karen_Broome <at> spe.sony.com [mailto:Karen_Broome <at> spe.sony.com]
<br>
Sent: 28 June 2006 01:06<br>
To: Debbie Garside<br>
Cc: 'Doug Ewell'; 'LTRU Working Group'<br>
Subject: Re: [Ltru] Preliminary Investigation into Application of ISO
11179<br>
<br><br>
Debbie, <br><br>
Did you review all of ISO 11179 or just 11179-6? <br><br>
There is a lot more to ISO 11179 than just the administrative practices
(-6) and the previous parts discuss a hierarchical metadata model not mentioned
in your review below. I think you're confusing the terms "value"
and "representation" and the other sections provide clarity on
this. &nbsp;The top of the hierarchy is the Data Concept, which is an abstract
description independent of its representation -- a pure semantic layer.
<br><br>
The hierarchy, as I understand it, would be something like this:
<br><br>
Data Concept <br>
 &nbsp; &nbsp; &nbsp; &nbsp;Language Code: A standardized code used to
identify a particular language or dialect. <br><br>
Data Elements [Data Concept + Representation Class] related to "Language
Code" data concept = 
<br>1. &nbsp; &nbsp; &nbsp; &nbsp;ISO
639-1 Language Code: &nbsp;A two-letter code assigned by the ISO 639-1
standard to identify a particular language. 
<br>2. &nbsp; &nbsp; &nbsp; &nbsp;ISO
639-2/B Language Code 
<br>3. &nbsp; &nbsp; &nbsp; &nbsp;ISO
639-2/T Language Code 
<br>4. &nbsp; &nbsp; &nbsp; &nbsp;ISO
639-3 Language Code 
<br>5. &nbsp; &nbsp; &nbsp; &nbsp;ISO
639-6 Language Code
<br><br>
Value Domain <br>
 &nbsp; &nbsp; &nbsp; &nbsp;Each data element in this case has a "Value
Domain" and the Value Domain contains the individual values such as
"en-US". <br><br>
... <br><br>
For the Language Code data concept, the ISO 11179 structure seems relevant
and useful. But when we look at some of the other concepts, it seems less
useful and perhaps problematic: <br><br>
Data Concept = Script Code <br>
Data Element = ISO 15924 Script Code <br><br>
Data Concept = Country Code <br>
Data Element = ISO 3166 Country Code <br><br>
Note that "Description" or even "Subtag Description"
is too vague by ISO 11179 rules (subjective judgment, but there are a lot
of examples that support this view) and I think you would need to break
these out as: 
<br>1. &nbsp; &nbsp; &nbsp; &nbsp;En-US
Language Name 
<br>2. &nbsp; &nbsp; &nbsp; &nbsp;Fr-FR
Language Name 
<br>3. &nbsp; &nbsp; &nbsp; &nbsp;En-US
Script Name 
<br>4. &nbsp; &nbsp; &nbsp; &nbsp;En-US
Country Name
<br>etc. <br><br>
These are unique data elements relating to several data concepts, so the
current model with its "Description" field would need serious
revision to be compliant, I think. <br><br>
I'm not opposed to further discussion of this moving forward. I only question
how valuable this is for a standard that has so few data elements. It is
a good thing that you're familiar with the section of the standard I've
spent the least time reviewing. &nbsp;:) <br><br>
Best regards, <br><br>
Karen Broome<br>
Sony Pictures Entertainment<br><br><br>
<table width="100%"><tr valign="top">
<td width="46%">"Debbie Garside"
&lt;debbie <at> ictmarketing.co.uk&gt; 
<p>06/27/2006 01:22 AM

</p>
</td>
<td width="53%">
<br><table width="100%">
<tr valign="top">
<td width="12%">
<div align="right">To</div>
</td>
<td width="87%">"'LTRU Working Group'"
&lt;ltru <at> ietf.org&gt; 
</td>
</tr>
<tr valign="top">
<td>
<div align="right">cc</div>
</td>
<td>'Doug Ewell' &lt;dewell <at> adelphia.net&gt;

</td>
</tr>
<tr valign="top">
<td>
<div align="right">Subject</div>
</td>
<td>[Ltru] Preliminary Investigation into
Application of ISO 11179</td>
</tr>
</table>
<br><br><table width="100%"><tr valign="top">
<td width="50%">
</td>
<td width="49%"></td>
</tr></table>
<br>
</td>
</tr></table>
<br><br><br><br>
Findings of a preliminary investigation into the application of ISO 11179
to<br>
the RFC3066bis Registry<br><br>
Cost<br>
Initial investigations suggest that ISO 11179 can be applied to the Registry<br>
at a base level for very little cost. &nbsp;The main cost is in mapping
the ISO<br>
11179 terminology to the existing Registry terminology and a number of<br>
additional data elements would be required. &nbsp;The Registry already<br>
incorporates a system of metadata elements that are consistent with the<br>
model presented within ISO 11179. &nbsp;<br><br>
In particular the value of the following aspects of ISO 11179-6 should
be<br>
investigated: <br><br>
Identification<br>
The attributes registration authority identifier (RAI), data identifier<br>
(DI), and version identifier (VI) constitute the international registration<br>
data identifier (IRDI). At least one IRDI is required for an administered<br>
item. <br><br>
Data identifiers are assigned by a Registration Authority; data identifiers<br>
shall be unique within the domain of a Registration Authority. <br><br>
Requirements for a Registration Authority, and a discussion of the IRDI,<br>
appear in ISO/IEC 11179-6.<br><br>
As each Registration Authority may determine its own DI assignment scheme,<br>
there is no guarantee that the DI by itself will uniquely identify an<br>
administered item. For example, if two authorities both use sequential<br>
6-digit numbers, there may be two administered items with the same DI's;<br>
however, the administered items will almost certainly not be the same.
<br><br>
If one administered item appears in two registers, it will have two DI's.<br>
Therefore, both the DI and the RAI are necessary for identification of
an<br>
administered item. <br><br>
If particular attributes of an administered item change, then a new version<br>
of the administered item shall be created and registered. The registrar<br>
shall determine these attributes. In such a case, a VI is required to<br>
complete the unique identification of an administered item.<br><br>
For further guidance, see ISO/IEC 11179-6. <br><br>
An IRDI can serve as a key when exchanging data among information systems,<br>
organizations, or other parties who wish to share a specific administered<br>
item, but might not utilize the same names or contexts.<br><br>
ISO/IEC 11179 does not specify the format or content of a unique DI.<br><br>
The IETF (or LTRU) would need to apply for an International Code Designator<br>
(ICD) - a four integer code; this coupled with the organization name as
well<br>
as a "department" identifier (OPI) becomes the IRDI e.g. 1234.IETF.LTRU.<br>
The ICD would be registered by the RA of ISO/IEC 6523 Organization Codes
as<br>
Registration Authority Identifier which is currently BSI. &nbsp;<br><br>
Implications for the LTRU Registry<br>
The DI (or UI - Unique Identifier) cannot be the Subtag as there are already<br>
conflicting Subtags within the registry (e.g. cy/CY). &nbsp;It is more
preferable<br>
that the unique identifier be the chosen language/country/script name<br>
(please note, this is not the preferred name). &nbsp;This would fit with
the<br>
current ISO 639-3, -5 and -6 models and open the Registry to adoption by<br>
meta-data knowledge grids. (I will take a good look at the naming<br>
conventions within ISO 3166-1 at a later date but prior to publication
of<br>
FDIS 3166-1). &nbsp;<br><br>
Anomalies within ISO naming conventions of standards issued prior to the<br>
adoption of ISO 11179 can be dealt with on a case by case basis via set<br>
rules. &nbsp; <br><br>
The Subtag would become a "Representation" with the name being
the unique<br>
"Data Identifier". This would involve having a "Primary
Description" which<br>
would form the DI.<br><br>
In reviewing the "Required Metadata Attributes" for a "Preferred
Standard"<br>
Status administered item, preliminary investigations reveal no serious<br>
additional requirements other than those already mentioned here. Some<br>
manipulation and interpretation of registry data and standard mandatory<br>
requirements would be required but no difficulties are envisaged. I would<br>
refer the WG to ISO/IEC 11179-6:2005(E); Table B-8 (p.34)<br><br>
Benefits<br>
The ISO 11179 model allows for there being conflicting codes between<br>
different meta-data registries in conformity with ISO 11179; that is part
of<br>
the conceptual model. &nbsp;("in conformity with" is correct
- there are<br>
essential parts of the standard).<br><br>
In essence, the ISO 11179 meta-model supports linkage to other ISO 11179<br>
conformant meta-data registries thus facilitating data exchange/interchange<br>
whilst giving the LTRU Registry ownership of the data elements contained<br>
therein - they become LTRU elements giving room for manoeuvre should ISO
get<br>
it wrong.<br><br>
This will make language tags more meaningful in the future. &nbsp;The key
word<br>
here is "linkage". &nbsp;ISO 11179 conformant meta-data registries
facilitate the<br>
creation of knowledge grids, grid computing and the semantic web!<br><br>
Conclusion<br>
At first glance the cost/value ratio favours ISO 11179; there appears to
be<br>
very little cost yet the true benefits of future interoperability and data<br>
exchange are unknown. &nbsp;<br><br>
It is recommended that further investigation be conducted before application<br>
of ISO 11179 can be discussed at WG level. <br><br>
Further benefits with regard to data interchange should be explored.<br><br>
It is further recommended that the "investigation into application
of ISO<br>
11179 Meta Data Registries to the Registry and its registration procedures<br>
be conducted by nominated members of the WG with a view to application"
be<br>
added to the new LTRU Charter. &nbsp;<br><br>
Best regards<br><br><br>
Debbie Garside<br><br><br><br>
_______________________________________________<br>
Ltru mailing list<br>
Ltru <at> ietf.org<br>
https://www1.ietf.org/mailman/listinfo/ltru<br><br>
<br>
</div>
Randy Presuhn | 6 Jul 19:30 2006
Picon

Charter - sign(ed) language tag construction ?

Hi -

As a technical contributor...

Would it make sense to add material on how tagging for sign(ed)
languages to the 3066ter effort being proposed?  If so, could
Peter's message be distilled down to a high-level sentence for
the charter discussion?

Randy

----- Original Message ----- 
From: "Peter Constable" <petercon <at> microsoft.com>
To: "IETF Languages Discussion" <ietf-languages <at> iana.org>
Sent: Tuesday, February 28, 2006 12:22 AM
Subject: RE: Language Subtag Registration Form: variant "signed"

I had an hour conversation today with an SIL linguist that has been assisting teams working on sign language
projects for a number
of years. We discussed various things, including the phenomenon of "signed-spoken-lang-X" varieties.

In thinking about how to construct tags for these languages, the crucial question in my mind is this (using
"signed English" in the
US as an example):

Is signed English

1) basically English expressed in a different modality,
2) basically ASL with some kind of modification or qualification -- e.g. a dialect or register, or
3) a pidgin of English and ASL?

Whichever it is, we should tag it accordingly (and if three, then possibly code as though it were a distinct language).

I was thinking we might use a subtag "-signed" based on the assumption that (1) was applicable. I know
understand that these
language varieties typically fall into (2), though perhaps sometimes into (3); generally these are
probably best thought of as
registers of the relevant signed language. They typically use phonology and lexica from the sign language
and impose elements of the
syntax (possibly including morphology) of the spoken language.

Thus, here's my thoughts on a good approach to tagging signed languages:

- We treat "sgn" as though it were a macrolanguage. (My contact said that really wasn't that much of a stretch.)

- We use ISO 639-3 IDs as extlang subtags together with a primary subtag of "sgn"; e.g., "sgn-ase" for ASL.
All signed languages
(SLs proper, not the Signed English cases) use tags constructed this way.

- We generally treat varieties like Signed English as registers of the signed language they are associated
with. Thus, the tag is
formed by adding a variant subtag to the tag for the sign language. Because there can be multiple varieties
for a given sign
language/spoken language combination, registered variant subtags provide the necessary level of
flexibility. E.g. something like
"sgn-ase-enexact" "sng-ase-enexact2" for SEE and SEE2; and "sgn-ase-esbaja" for the signed Spanish
spoken in southern Baja
California (which is based on ASL).

- For cases of signed-spoken-lang-X that are pidgins, we treat these based on whatever general principles
we adopt for pidgins. (I'm
not sure at the moment what that should be; the problem with pidgins is that they are transitional and not yet
stable -- they may
stabilize as a creole or they may continue to mutate or they may disappear.)

This should give generally good results for matching algorithms. Having "sgn" at the start immediately
sets apart the modality,
which will generally trump any other distinction in importance to the user. A request for "sgn-ase" will
return results that include
(the hypothetical) "sgn-ase-enexact" and "sgn-ase-esbaja", which is likely to be reasonable: an ASL
speaker is going to recognize
all or nearly all of the lexical items in either case and so will have about as much problem in comprehension
as we'd expect from
dialect or register differences.

This is a preliminary take. I'm know my understanding is still limited, and that are likely to be several
parts of what I've
outlined that need work and further discussion.

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


Gmane