ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-idng] Draft on String Similarity

  • To: gnso-idng@xxxxxxxxx
  • Subject: Re: [gnso-idng] Draft on String Similarity
  • From: Avri Doria <avri@xxxxxxx>
  • Date: Sat, 12 Dec 2009 23:47:23 +0100

Hi,

Good quote.

Which say to me that it is a complex issue, but that visual similarity is the 
predominant factor i determining confusion.  And only in cases where you can 
expect the a person to know both languages would meaning enter into the issue 
as a complicating factor.  Likewise for phonetic comparisons.

So yes, confusion is the key.

Most can be eliminated based on visual confusion.

And for the others where there really is a complicating factor that may cause 
confusion, then and only then does phonetics and meaning come in - and it comes 
in at the challenge level.

At least that is how I read it.  In no way can I read as saying that phonetics 
or meaning may be predominant or primary factors in confusion.

But yes, meaning is mentioned.

a.



On 12 Dec 2009, at 23:18, Gomes, Chuck wrote:

> 
> Here's a quote from the GNSO recommendations regarding Recommendation 2:
> 
> "x) A number of different trademark offices provide guidance on how to 
> interpret confusion. For example, the European Union Trade Mark Office 
> provides guidance on how to interpret confusion. "...confusion may be visual, 
> phonetic or conceptual. A mere aural similarity may create a likelihood of 
> confusion. A mere visual similarity may create a likelihood of confusion. 
> Confusion is based on the fact that the relevant public does not tend to 
> analyse a word in detail but pays more attention to the distinctive and 
> dominant components. Similarities are more significant than dissimilarities. 
> The visual comparison is based on an analysis of the number and sequence of 
> the letters, the number of words and the structure of the signs. Further 
> particularities may be of relevance, such as the existence of special letters 
> or accents that may be perceived as an indication of a specific language. For 
> words, the visual comparison coincides with the phonetic comparison unless in 
> the relevant la!
> nguage the word is not pronounced as it is written. It should be assumed that 
> the relevant public is either unfamiliar with that foreign language, or even 
> if it understands the meaning in that foreign language, will still tend to 
> pronounce it in accordance with the phonetic rules of their native language. 
> The length of a name may influence the effect of differences. The shorter a 
> name, the more easily the public is able to perceive all its single elements. 
> Thus, small differences may frequently lead in short words to a different 
> overall impression. In contrast, the public is less aware of differences 
> between long names. The overall phonetic impression is particularly 
> influenced by the number and sequence of syllables." (found at 
> http://oami.europa.eu/en/mark/marque/direc.htm)." 
> 
> Chuck
> 
>> -----Original Message-----
>> From: owner-gnso-idng@xxxxxxxxx 
>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Tim Ruiz
>> Sent: Saturday, December 12, 2009 10:31 AM
>> To: gnso-idng@xxxxxxxxx
>> Subject: RE: [gnso-idng] Draft on String Similarity
>> 
>> 
>> Just one other note/correction, in reality the DAG doesn't 
>> meantion meaning at all in conjunction with the similarity 
>> test. The overarching issue with similarity is the 
>> "probability of user confusion." Could meaning be a part of 
>> that? Possibly, but that is a difficult test, especially when 
>> considering various languages/IDNs.
>> 
>> Tim
>> 
>> -------- Original Message --------
>> Subject: RE: [gnso-idng] Draft on String Similarity
>> From: "Tim Ruiz" <tim@xxxxxxxxxxx>
>> Date: Sat, December 12, 2009 9:22 am
>> To: "Gomes,Chuck" <cgomes@xxxxxxxxxxxx>
>> Cc: gnso-idng@xxxxxxxxx, "Avri Doria" <avri@xxxxxxx>
>> 
>> 
>>> Not sure what you are disagreeing with.
>> 
>> As I said below regarding the draft statement, I agree with 
>> Avri that there not be any solution offered, but only a 
>> problem statement.
>> 
>> My other comments are in regards to what I perceived as 
>> intent to apply a more broad application of meaning within 
>> the similarity test. Whether intended or not, the solutions 
>> offered in 1. and 2. in the draft statement do just that.
>> 
>> Tim
>> 
>> -------- Original Message --------
>> Subject: RE: [gnso-idng] Draft on String Similarity
>> From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
>> Date: Sat, December 12, 2009 9:00 am
>> To: "Tim Ruiz" <tim@xxxxxxxxxxx>
>> Cc: <gnso-idng@xxxxxxxxx>, "Avri Doria" <avri@xxxxxxx>
>> 
>> 
>> Tim,
>> 
>> Meaning similarity just like visual or other similarity may 
>> be used to determine the probability. Not sure what you are 
>> disagreeing with.
>> 
>> Chuck 
>> 
>>> -----Original Message-----
>>> From: Tim Ruiz [mailto:tim@xxxxxxxxxxx]
>>> Sent: Saturday, December 12, 2009 9:43 AM
>>> To: Gomes, Chuck
>>> Cc: gnso-idng@xxxxxxxxx; Avri Doria
>>> Subject: RE: [gnso-idng] Draft on String Similarity
>>> 
>>> That's not true Chuck, at least not in the broad sense as 
>> you state it 
>>> and as implied at various times by some on this list.
>>> 
>>> In the current version of the DAG meaning is only 
>> considered in a very 
>>> limited sense - to determine if there is a probability (not just the
>>> possibility) of user confusion. What I am concerned about is any 
>>> attempt to take it beyond that. In other words, .business 
>> should not 
>>> be found confusingly similar to .biz, and .athletics should not be 
>>> found confusingly similar to .sports. Those may not be the best 
>>> examples, but you get the idea.
>>> 
>>> Otherwise, the door is open for gTLD operators or others to use the 
>>> similarity test to attempt to limit competition.
>>> 
>>> 
>>> Tim
>>> 
>>> -------- Original Message --------
>>> Subject: RE: [gnso-idng] Draft on String Similarity
>>> From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
>>> Date: Sat, December 12, 2009 8:05 am
>>> To: "Tim Ruiz" <tim@xxxxxxxxxxx>, "Avri Doria" <avri@xxxxxxx>
>>> Cc: <gnso-idng@xxxxxxxxx>
>>> 
>>> The GNSO new gTLD recommendations approved by the Board and 
>> hence the 
>>> implementation in the DAG already include meaning so it 
>> would require 
>>> a policy change to exclude meaning.
>>> 
>>> Chuck
>>> 
>>>> -----Original Message-----
>>>> From: owner-gnso-idng@xxxxxxxxx
>>>> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Tim Ruiz
>>>> Sent: Friday, December 11, 2009 5:45 PM
>>>> To: Avri Doria
>>>> Cc: gnso-idng@xxxxxxxxx
>>>> Subject: RE: [gnso-idng] Draft on String Similarity
>>>> 
>>>> 
>>>> I don't believe that the definition of similar should
>>> include meaning.
>>>> In fact, including it opens up even more serious problems
>>> than those
>>>> you are trying to solve. So I agree with Avri that there 
>> not be any 
>>>> solution offered, but only a problem statement.
>>>> 
>>>> 
>>>> Tim
>>>> 
>>>> -------- Original Message --------
>>>> Subject: Re: [gnso-idng] Draft on String Similarity
>>>> From: Avri Doria <avri@xxxxxxx>
>>>> Date: Fri, December 11, 2009 8:41 am
>>>> To: gnso-idng@xxxxxxxxx
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> On first reading a few things:
>>>> 
>>>> - to prevent inflaming tensions, I recommend you not use a
>>> strong that
>>>> many would think a ccTLD as an example. yes I totally
>>> understand it is
>>>> just an example, but I think we would be better off, and
>>> the argument
>>>> simpler, with a string like .duck and it translations.
>>>> 
>>>> - while I know some of you think that the battle over similarly 
>>>> including meaning is a completed discussion, I for one, do
>>> not agree.
>>>> Not because I think it isn't relevant to the discussion of some 
>>>> challenges, but because the determination of 
>> similarity/identity in 
>>>> meaning in trasnlation and ideas of demarkation in those
>>> cases are not
>>>> cut and dried. I therefore think it more appropriate to say:
>>>> 
>>>>> First, for some the current meaning of "similar" is now
>>>> broader than "visual similarity", and appears to include 
>> "meaning".
>>>> 
>>>> I ask does the extended definition of similar include
>>> transliteration
>>>> and homonyms for some as well as translation?
>>>> 
>>>> - i believe that we should just be stating the problem and not a 
>>>> solution. We do not have a consensus on the solution - nor is 
>>>> continuing with discussion to find a compromise solution
>>> something i
>>>> think in the design teams charge unless the council suggest
>>> it is. I
>>>> still think the process as it stands may be adequate, but I
>>> think it
>>>> needs more study in terms of these questions. Hence, I 
>> think it is 
>>>> important that the issue be flagged. I recommend cutting out the 
>>>> solution section completely. If we don't it, then we need
>>> to expand it
>>>> to all include all the possible solution we can think of and that 
>>>> would be time consuming.
>>>> 
>>>> - I did not understand your point about the restriction to UN 
>>>> languages in the root.
>>>> 
>>>> Otherwise, I think it is close and rather good.
>>>> 
>>>> thanks for taking the first cut and subjecting it to my comments.
>>>> 
>>>> a.
>>>> 
>>>> 
>>>> On 11 Dec 2009, at 15:11, Eric Brunner-Williams wrote:
>>>> 
>>>>> 
>>>>> Councilors,
>>>>> 
>>>>> During the past weeks the participants in the
>>>> gnso-idng@xxxxxxxxx mailing list (IDNG) have discussed, on
>>> the mailing
>>>> list and in conference calls, aspects of the situation 
>> which exists 
>>>> following the Board's vote at Seoul.
>>>>> 
>>>>> One area of discussion which raises a policy issue is
>>>> confusingly similar strings. Because this seems an area where the 
>>>> obvious right thing has already been done we need to draw
>>> attention to
>>>> two aspects which have been overlooked.
>>>>> 
>>>>> First, the current meaning of "similar" is now broader than
>>>> "visual similarity", and appears to include "meaning".
>>>>> 
>>>>> Second, the underlying assumption in the evaluation process
>>>> is that each evaluation is independent of all other evaluations.
>>>>> 
>>>>> These, a rule (about a string in an application) and a
>>>> meta-rule (about all applications), have a consequence which we 
>>>> suggest is not desirable.
>>>>> 
>>>>> In the following example we use "china" and "中国" (chung
>>>> guo), simply as a well-known example of two strings. We 
>> ignore that 
>>>> both are part of the universe of strings more likely to 
>> pertain to 
>>>> ccTLD and their policy body than the GNSO, for the purpose of 
>>>> illustrating the policy problem.
>>>>> 
>>>>> The string "china" and "中国" (chung guo) are "similar" in
>>>> meaning, therefor they form a contention set. Under the
>>> current rules
>>>> in DAGv3, only one application who's string is a member of a 
>>>> contention set may proceed towards delegation.
>>>> Whether the choice is by order of creation, or amongst
>>> contemporaries,
>>>> by community evaluation and/or auction, the result is the 
>> same. One 
>>>> member of an (extended, in the sense of including existing
>>> registries)
>>>> contention set thrives. All others fail.
>>>>> 
>>>>> This is the proper and correct end, except for one case
>>>> which is more likely to exist for applications for IDN 
>> strings than 
>>>> for restricted ASCII (letters, digits, hyphen) strings.
>>> That case is
>>>> where two, or more, applications for similar strings are
>>> advanced by a
>>>> single applicant, or two or more cooperating applicants.
>>>>> 
>>>>> Returning to our "china" and "中国" (chung guo) example, 
>> if XYZ Co. 
>>>>> applied for both "china" (application #1) and "中国" 
>>>> (application #2), the current rules can not allow both strings to 
>>>> exist in the root, though both are brought by the same applicant.
>>>>> 
>>>>> The fundamental rational is that confusion is harmful. This
>>>> rational is not universally correct. There are instances where 
>>>> confusion results in no harm, and more importantly, where
>>> "confusion" 
>>>> creates benefit.
>>>>> 
>>>>> Because "beneficial confusion" is not obvious to users of
>>>> Latin Script, an example, we offer the original example of
>>> cooperation
>>>> among "applicants" to benefit their registrants and 
>> users, through 
>>>> "similarity".
>>>>> 
>>>>> In 2001, the registries for China, Taiwan, Hong Kong and
>>>> Macao discussed cooperation so that mixing of Simplified Chinese, 
>>>> prevalent in China, and Traditional Chinese, prevalent in
>>> Taiwan, but
>>>> interchangeable without loss of meaning, would not result in user 
>>>> confusion. These "applicants" cooperated to create "beneficial 
>>>> confusion", so that "similar strings" actually had 
>> similar meaning, 
>>>> that is, resolved as expected by their user community.
>>>>> 
>>>>> No user "confusion" resulted from this multi-applicant
>>>> cooperation, except perhaps in Marina del Rey.
>>>>> 
>>>>> Coordination to create "beneficial confusion" may exist
>>>> where one applicant submits two or more applications, as in the 
>>>> "china" and "中 国" (chung guo) example, or where two or more
>>> applicants
>>>> submit two or more applications, as the four cooperating Chinese 
>>>> registries did, almost a decade ago.
>>>>> 
>>>>> It is possible that applicants for two or more similar
>>>> strings could, upon failure, resort to extended evaluation,
>>> where the
>>>> cause of the failure is similarity with an existing TLD. Present 
>>>> registries seeking similar IDN delegations could simply 
>> cost in the 
>>>> extended evaluation cost as part of the application cost. This is 
>>>> inelegant, but not fatally so.
>>>>> 
>>>>> Unfortunately, for applicants simply seeking two or more
>>>> delegations with similar meaning, independent of script, 
>> as in the 
>>>> "china" and "中 国" (chung guo) example, initial evaluation
>>> failure and
>>>> extended evaluation are not available.
>>>> The contention set consisting of two strings and one actual
>>> applicant
>>>> go to auction, with absurd outcome from the business
>>> perspective, and
>>>> tragic outcome from the language perspective, as one 
>> script choice 
>>>> eliminates all others, for some meaning defined construction of 
>>>> "similarity".
>>>>> 
>>>>> We suggest the Council consider the following to cure 
>> this defect.
>>>>> 
>>>>> 1. that the meta-rule that all applications are
>>>> independently evaluated be modified so that cooperating
>>> applications
>>>> may, if the contention set they form contains no non-cooperating 
>>>> applications, proceed in the evaluation process.
>>>>> 
>>>>> 2. that the rule that applications for strings which are
>>>> "confusingly similar" to existing registries, where the
>>> application is
>>>> brought by the existing registry to which "confusing similarity" 
>>>> exists, be modified so that these applications do not fail
>>> the initial
>>>> evaluation and require extended evaluation, or some other heroic 
>>>> measure.
>>>>> 
>>>>> Both of these recommendations have generalizations.
>>>>> 
>>>>> The independent applications presumption overlooks the
>>>> certainty that the legacy operator and application authors
>>> of 2000 and
>>>> 2003-2006, and new authors, will each author multiple 2010 
>>>> applications, some of which have common characteristics, such as 
>>>> "similarity" and "cooperation", and absent a mechanism to
>>> "signal" the
>>>> similarity to the evaluation process, adverse outcomes 
>> and process 
>>>> inefficiencies are certain.
>>>>> 
>>>>> A property common to two or more applications should be
>>>> discoverable by the evaluation process, especially when the
>>> applicants
>>>> desire this common property to be known to the evaluation process.
>>>>> 
>>>>> The presumption of user confusion and harm where similarity
>>>> exists overlooks the utility of similarity, and more profoundly, 
>>>> substitutes a Marina del Rey centric meaning and utility
>>> test for the
>>>> meanings and uses that exist at large.
>>>>> 
>>>>> Correct use by two or more applications, that is, a
>>>> property common to only the strings sought by two or more 
>>>> applications, can, and should be discoverable by the evaluation 
>>>> process.
>>>>> 
>>>>> The Council need not necessarily look to the
>>>> generalizations of the modifications of rule and meta-rule
>>> we suggest
>>>> to cure the anticipated problem of similar strings in IDN 
>>>> applications, but should it do so, the IDNG participants
>>> are prepared
>>>> to further inform the Council.
>>>>> 
>>>>> As it stands, the IDNG participants now understand the
>>>> unintended effect of the "similarity" rule, and the "independent 
>>>> application" meta-rule, to be that only one of the six UN 
>> languages 
>>>> may be used for any identifier in the root, with adverse
>>> consequences
>>>> for cooperation and harmonization of operational practice 
>> and user 
>>>> expectations.
>>>>> 
>>>>> The IDNG participants thank the Council for its time and
>>>> attention considering the its initial work product.
>>>>> 
>>>>> 
>>>>> This ends the draft. Chuck, Edmond, Avri, edit to your
>>>> heart's content.
>>>>> 
>>>>> Eric
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy