Subject: [Ltru] Status of matching draft? (was: Re: weights in scored filtering)

From: "Doug Ewell" <[email-masked]>
Date: Sun, 8 Jan 2006 10:31:25 -0800

The last message on this list that was relevant to the progress of our 
only remaining work item was on December 21, 18 days ago.  We were 
talking about q-values and whether users could see, understand, or 
customize them, and about Harald's suggestion to assign explicit numeric 
weights to items in lists.

There have been other messages since then, but they don't seem to be 
related to getting the matching draft done.

Can we resolve the remaining issues with draft-matching-08, generate a 
new draft, and start assessing (again) how close we are to WG Last Call? 
I hate to see the group stagnating while there is still work to do, and 
if it is true that none of our documents will be published until all are 
approved, then we are causing unnecessary delay for users who want to 
use the new mechanism.

--
Doug Ewell
Fullerton, California, USA
http://users.adelphia.net/~dewell/

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

---

From: r&d afrac <[email-masked]>
Date: Sun, 08 Jan 2006 20:40:35 +0100

At 19:31 08/01/2006, Doug Ewell wrote:
>The last message on this list that was relevant to the progress of 
>our only remaining work item was on December 21, 18 days ago.  We 
>were talking about q-values and whether users could see, understand, 
>or customize them, and about Harald's suggestion to assign explicit 
>numeric weights to items in lists.
>
>Can we resolve the remaining issues with draft-matching-08, generate 
>a new draft, and start assessing (again) how close we are to WG Last 
>Call? I hate to see the group stagnating while there is still work 
>to do, and if it is true that none of our documents will be 
>published until all are approved, then we are causing unnecessary 
>delay for users who want to use the new mechanism.

Dear Doug,
the Tunis agreement was reached a few hours before the IESG approved 
the RFC 3066 bis Draft. This was exactly the sequence I wished. It 
now permits a more serene approach.

In this stabilised context there is an analysis to carry. It is to 
understand what belongs to an internationalized-US-ASCII Internet and 
to what belongs to the multilingual/multicultural harmonisation of 
the International Network. Also, if one can be considered as a 
unilateral default of the multilateral or cross-lateral other. Who 
has the competence, the responsibility, the budget, and the ethical 
and cultural legitimacy for hosting such a debate, and the resulting 
registries.

Your registry is a stable element as it reproduces three ISO 
standards. It is in the IANA.

The RFC 3066 bis Draft can be patched to make its ABNF consistent 
with reality. It will probably not fly otherwise.

The filtering issue is more uncertain as there is a need to fully 
understand its purpose. There are obviously additional risks exposed 
by the two-tiered Internet, where langtags may permit lingually 
discriminatory service quality. People are also concerned about the 
CLDR project and its relations with the USG/DoD strategies (from 
meeting annouces by Unicode).

Meetings have been hold on various related issues (IDNs, 
discrimination, profiling, network architecture). They show the whole 
topic is not stabilized yet. Hence probably not motivating. RFC 3066 
bis proposes a language network naming and filtering system. 
Questions are now what is the use of a name for a language if the 
language is not identified by its user (what none did during the last 
7.000 years)? how does it help/hampers the use of the language in the 
network? Same for filtering.

I introduced an appeal to the IAB to try to clarify if 
multilingualism belongs or not to the IETF. I suppose advisable to 
wait for the response Leslie Daigle said the IAB will do. May be also 
to see how the NSF follows on Tunis and includes lingual support, and 
how, in GENI. What will be the trend for the IGF.

Sorry if this does not match your impatience. It also tries to 
explain the silence.
All the best and happy new year.
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 09 Jan 2006 01:28:01 +0100

--On søndag, januar 08, 2006 10:31:25 -0800 Doug Ewell 
<[email-masked]> wrote:

> approved, then we are causing unnecessary delay for users who want to use
> the new mechanism.

Seconded.

Chairs, are you thinking about creating an open issues list for the 
matching draft? I haven't seen tickets for a while here....

               Harald

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 09 Jan 2006 01:59:20 +0100

Doug Ewell wrote:

> if it is true that none of our documents will be published
> until all are approved

I don't share that fear, it's a subtle point that the old BCP
also covered some kind of matching, and that "we" split that
issue from the new RFC.  Anything about the new registry and
the new registration procedure is ready.  You could post your
collected post-date-B updates on the languages list whenever
it pleases you.

There are also many missing Suppress-Script values.  I've noted
one of the new "fy" where I'd know how to find some "official
evidence" for a registration of "Latn" (better than Google or
Wikipedia).

> we are causing unnecessary delay for users who want to use
> the new mechanism.

A short delay is no serious problem.  Early adopters trusting
that the Suppress-Scripts are complete and publishing numerous
explicit scripts in new language-tags could be in trouble.

For the matching draft what I recall is:  The ABNF for ranges
is in essence ready, no showstoppers in sight.  Details about
interpreting missing subtags (with zero or more explicit "*")
are IIRC also ready.

For the implementation details, e.g. "scoring" with precise
numerical values, or "distance metric", we ran into problems,
there are too many ways to get it more or less right and
obviously wrong.

Maybe the scoring should be only an "informative example",
pointing out some potential features plus traps and pitfalls,
but not normative.

"Number of variants is in theory unlimited" was one issue, and
8-4-2-1 won't fly if you want four independent dimensions with
"region more important than whatever variants".

Maybe we could shrink it to "language + script + details" (?)
Explaining the effects if one or both sides have no script wrt
Suppress-Script.

Personally I'm also interested in two examples "I want Latn"
as first priority (before the language), and "precisely this
variant, no matter what the region is".

For lists of ranges we should explain that this could be a
simple OR (same weight), or an ordered list, and how to get
these effects with scoring of the matches plus q-values for
the ranges.

Maybe we should simply say that "lists of ranges" are out of
scope for the matching draft, and focus on the matching for
one range.  With a note that scoring plus q-values for ranges
could extend this concept to lists of more than one range.

That's how I recall the discussion, but I probably missed some
points.  IMO we're seriously in trouble when we try to discuss
"integer arithmetic", "percent scales", or other implementation
details.
                               Bye, Frank

---

From: Mark Davis <[email-masked]>
Date: Mon, 09 Jan 2006 14:45:09 -0800

I agree that we need to push this along (I've been out for about 2 weeks).

Returning to the subject of weighting. Harald wrote the following 
(below). From the RFCs referencing Q values, the RFCs that reference it 
just don't specify what happens. Here is an example:

If no Q
   values are given, the language-ranges are given in priority order,
   with the leftmost language-range being the most preferred language;
   this is an extension to the HTTP/1.1 rules, but matches current
   practice.
-- ftp://ftp.isi.edu/in-notes/rfc3282.txt

   The language quality factor assigned to a language-tag by the
   Accept-Language field is the quality value of the longest language-
   range in the field that matches the language-tag. If no language-
   range in the field matches the tag, the language quality factor
   assigned is 0. If no Accept-Language header is present in the
   request, the server
   SHOULD assume that all languages are equally acceptable. If an
   Accept-Language header is present, then all languages which are
   assigned a quality factor greater than 0 are acceptable.
-- ftp://ftp.isi.edu/in-notes/rfc2616.txt

My misgivings are that when I specify "fr,  de, en;q=0.9" it says 
nothing about the priority of the two. It could be that they are 
completely equal in priority, and I just have to put one of them first, 
or it could be that fr is by far the best, and I can just barely make 
out German. So it could correspond to either of the following:

   "fr;q=1.0, de;q=1.0, en;q=0.9"
   "fr;q=1.0, en;q=0.9, de;q=0.1"

(reordered by the resulting priority). Harald's proposal would make it 
be equivalent to

   "fr;q=1.0, en;q=0.9, de;q=0.75"

====

http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html

If we look at filtering in practice, we see two models.

1. Simplest
In Google, for example, you can specify that you either want to allow 
languages or not. All are equal -- so essentially all q values are 1.0 
or 0.0.

2. More sophisticated
Fancy systems will allow features like boolean combinations; eg the 
document contains ("cat" in English OR "Katze" in German OR "chat" in 
French ), where the priority of a language will depend on other 
requested characteristics. Thus a document containing "chat" in English 
(but not "cat") would be excluded from a match.

So I am not dead-set against including Harald's approach of each 
successive item being .75 times the previous, as long as we phrase it so 
that it is optional. However, I think it would really be simpler to just 
say that they get the same value as the preceeding item.

So, in toto, here is my suggested text to resolve this issue.

Replace the the last text paragraph of 3.2.3. Scored Filtering as follows.

<old>

Implementations or protocols sometimes might wish to use more 
sophisticated weights that depend on the values of the corresponding 
elements. For example, depending on the domain, an implementation might 
give a small distance to the difference closely related subtags. Some 
examples of closely related subtags might be:

</old>
<new>

Where a language priority list follows the syntax of the 
"Accept-Language" header defined in RFC 2616 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html#RFC2616>[RFC2616] 
(see Section 14.4) and RFC 3282 
<http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html#RFC3282> 
[RFC3282], language tags without a Q value are given values equal to the 
value of the previous language tag (processing from first to last). If 
the first language tag has no Q value, it is given a value of 1.0. Then 
language tags with zero Q values are removed. For example, "fr, 
en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5, de;q=0.5, it;q=0.5". The 
distance values given above are then divided by the Q values. For 
example, if "fr-FR has a distance of 384 and a Q value of 0.8, then the 
resulting resolved distance is 480.

Implementations or protocols may use different weighting systems than 
the ones described aboves, as long as the weightings and weighting 
mechanisms are clearly specified. Thus, for example, an implementation 
or protocol could give all language tags with missing Q values a value 
of 1.0, or give the distance value 1000 to a language mismatch. They may 
also wish to use more sophisticated weights that depend on the values of 
the corresponding elements. For example, depending on the domain, an 
implementation might give a small distance to the difference closely 
related subtags. Some examples of closely related subtags might be:

</new>

Mark

>
>
> Harald Tveit Alvestrand wrote:
>
> --On fredag, november 18, 2005 17:37:05 -0800 Mark Davis 
> <[email-masked]> wrote:
>
>> We can do an integer only approach. Convert the q's into round(100/q).
>>
>> For filtering, we can't assume anything about the order of items in the
>> list that have the same q values. I have en, de, fr, it, nl. But my
>> English is significantly better than my German, which is somewhat better
>> than my French, which is significantly better than my Italian, etc.
>>
>> For lookup, we and everybody I know just uses the q values to reorder 
>> the
>> list. Then throws them away. So for lookup, ordering is very important.
>
>
> If we want to have ordering and q values both "work", we might have to 
> bite the bullet and define them.... I'd suggest something like
>
> If an item in the list does not have a q value, its q value is assumed 
> to be 0.75 times the q value of the preceding item in the list.
> If the first item in the list does not have a q value, its q value is 
> assumed to be 1.
>
> So the two lists
>
>  en;q=1.0, fr;q=0.75, de
>
>  en, fr, de;q=0.5625
>
> would be completely identical.
> That at least gives us a consistent, and mostly intuitive, 
> interpretation of such lists.

Doug Ewell wrote:

> customize them, and about Harald's suggestion to assign explicit 
> new draft, and start assessing (again) how close we are to WG Last 
> Call? I hate to see the group stagnating while there is still work to 
> do, and if it is true that none of our documents will be published 
> until all are approved, then we are causing unnecessary delay for 
> users who want to use the new mechanism.
>
> -- 
> Doug Ewell

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2006 02:04:24 +0100

> say that they get the same value as the preceeding item.

Simpler, but (this came out when I was doing 3066) incompatible with 
current practice.

Browsers generally pretty consistently take the first match on the list; 
"equal weight" doesn't do that. (A difference of 0.0000001 would also do it 
"right", of course; 0.75 was just a number from a hat).

---

From: Mark Davis <[email-masked]>
Date: Mon, 09 Jan 2006 18:20:58 -0800

But that is current practice for *lookup*, not for *filtering*. Here is 
suggested language for the latter, just after Figure 10 in 
http://www.inter-locale.com/ID/draft-ietf-ltru-matching-07.html.

<new>
Where a language priority list contains Q values as in the syntax of the 
"Accept-Language" header defined in RFC 2616 [RFC2616] (see Section 
14.4) and RFC 3282 [RFC3282], language tags without a Q value are given 
values equal to the value of the previous language tag (processing from 
first to last). If the first language tag has no Q value, it is given a 
value of 1.0. Then language tags with zero Q values are removed. For 
example, "fr, en;q=0.5, de, it" becomes "fr;q=1.0, en;q=0.5, de;q=0.5, 
it;q=0.5". The language priority list is then sorted from highest 
priority to lowest, whereby any two language tags with the same Q values 
are remain in the same order as in the original language priority list. 
This list is then traversed as described above in doing lookup.

Implementations or protocols may use different lookup mechanisms systems 
than the ones described aboves, as long as those mechanisms are clearly 
specified.
</new>

This has the same effect as what you describe; if you have a list with 
no Q values, the first one matched is returned.

Mark

Harald Tveit Alvestrand wrote:

> Browsers generally pretty consistently take the first match on the 
> list; "equal weight" doesn't do that. (A difference of 0.0000001 would 
> also do it "right", of course; 0.75 was just a number from a hat).
>
>
>
>
>
>

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 10 Jan 2006 13:31:57 +0100

--On mandag, januar 09, 2006 18:20:58 -0800 Mark Davis 
<[email-masked]> wrote:

> But that is current practice for *lookup*, not for *filtering*.

OK, I didn't catch that you were proposing this for filtering only.

I continue to claim that making filtering behave inconsistently with lookup 
will be a decision we'll regret.

                   Harald

---

From: r&d afrac <[email-masked]>
Date: Tue, 10 Jan 2006 15:05:42 +0100

At 13:31 10/01/2006, Harald Tveit Alvestrand wrote:
>I continue to claim that making filtering behave inconsistently with 
>lookup will be a decision we'll regret.

Mark,
I am interested in the impact on usages. Could you document your 
position? Harald's position seems more users' consistent.
jfc

---

From: Mark Davis <[email-masked]>
Date: Wed, 11 Jan 2006 15:31:48 -0800

They have to be "inconsistent"; they are different processes with very 
different goals. In one case you are filtering for any content that 
matches X; in the other case, you are looking for the closest match that 
is not more specific. They necessarily have different outcomes.

Are there any other objections to the language additions I proposed, or 
can we accept them?

Mark

---

From: r&d afrac <[email-masked]>
Date: Thu, 12 Jan 2006 08:52:49 +0100

At 00:31 12/01/2006, Mark Davis wrote:
>They have to be "inconsistent"; they are different processes with 
>very different goals. In one case you are filtering for any content 
>that matches X; in the other case, you are looking for the closest 
>match that is not more specific. They necessarily have different outcomes.

In one case I want to be able to read a text, in the other I want to 
profile the author. Correct description?
jfc

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 12 Jan 2006 14:22:17 +0100

> is not more specific. They necessarily have different outcomes.

I'm not worried about the different outcomes (set versus single). I'm 
worried about the way the users will have to be trained differently if the 
proposals are as I understand them now.

In one, we'll have to train the users to specify their requirements with as 
little specificity as possible, and train the content taggers to use as 
much specificity as possible.

In the other, we have to train the users to overspecify their requirements, 
and train the content taggers to use the most general marking that does not 
overlap with another alternative.

I fear the resulting confusion.

My preferred solution is to specify "one way to do it" - that the result of 
a lookup is the same object as the most-preferred result of a ranked 
filtering, given the same list of input tags and the same list of tagged 
objects.

> Are there any other objections to the language additions I proposed, or

I think the language is fine for what it wants to accomplish. I don't agree 
with what it wants to accomplish.

                        Harald

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Jan 2006 15:32:52 +0100

Mark Davis wrote:
 
> They have to be "inconsistent"; they are different processes
> with very different goals. In one case you are filtering for
> any content that matches X; in the other case, you are
> looking for the closest match that is not more specific. They
> necessarily have different outcomes.

Thanks, that's something I hadn't seen so far.  When I look
for "de" and get a de-CH match, then I might miss de-CH-1996.
With a filter I'd get both.

The case "specified script is the Suppress-Script" is an
exception, a filter should also return all documents without
script subtag.
                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 12 Jan 2006 15:46:31 +0100

r&d afrac wrote:

> In one case I want to be able to read a text, in the other
> I want to profile the author. Correct description?

The second case has many potential usages:  Maybe you want to
do some further processing, e.g. implement a MOT operator for
ranges, or in the most simple case just select what you want
manually.

In my example "want de, and got de-CH" the second case would
allow me to pick de-CH-1996 instead of de-CH if available.

I could of course also ask for de-*-*-1996 when I know that
I like 1996.  But if I like 1996 only for de-CH and not de-DE
it's clumsy to get this effect in the first "best match" case.

                        Bye, Frank

---

From: r&d afrac <[email-masked]>
Date: Thu, 12 Jan 2006 16:56:22 +0100

The result of such a practice may actually be worse that Harald says. 
Some may want to enter data to get the result of one approach when 
they suspect the other end follows the other approach. If you add 
retro-meta-spam (sending meta-data to profile the responses you get) 
the confusion may be total. I do not object this :-) ! But all I can 
say: this is a real life problem resulting from the adopted 
architectural layer violation of represented by the language tag 
concept, internationalisation and of the lack of security in RFC 3066 bis.

What our two leaders document is that an author will be incited to 
write a text in Volapuk, to say it is in Ploutocratien, so it will be 
accepted by Australopitecan communities and come across the anti-spam 
filtering. The RFC 3066 Bis naming system has no other built-in 
security than trust. This point is in the text of the appeal under 
finalisation. But not as sophisticated as this. I need to update it now.

If I am correct and read you, we are going to see people using their 
langtags to trick Google to add their texts in other language 
searches, like when you search for "failure".

missa est.
jfc

At 14:22 12/01/2006, Harald Tveit Alvestrand wrote:
>I'm not worried about the different outcomes (set versus single). 
>I'm worried about the way the users will have to be trained 
>differently if the proposals are as I understand them now.
>
>In one, we'll have to train the users to specify their requirements 
>with as little specificity as possible, and train the content 
>taggers to use as much specificity as possible.
>
>In the other, we have to train the users to overspecify their 
>requirements, and train the content taggers to use the most general 
>marking that does not overlap with another alternative.
>
>My preferred solution is to specify "one way to do it" - that the 
>result of a lookup is the same object as the most-preferred result 
>of a ranked filtering, given the same list of input tags and the 
>same list of tagged objects.
>
>I think the language is fine for what it wants to accomplish. I 
>don't agree with what it wants to accomplish.
>
>                        Harald
>
>
>
>