Subject: [Ltru] RE: lookup/filtering semantics

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 14 Feb 2006 11:21:10 +0100 (CET)

John Cowan wrote:
> > If a * occurs in the middle or end of the tag pattern that is less
> > specific than having something (including empty?) in place of the *:
>
> Lacking a subtag has always been equivalent to being least specific:

Not in the basic scheme which only considers prefixes:
	ln-vrnt is NOT less than ln-CT-vrnt
in the basic scheme.

> if "country" is missing, then there is no specific country.

When I wrote "less specific" I meant strictly in the formal sense,
and will vary depending on the formal definitions of the comparisons.
To what extent any of them coinsides with an informal notion
"less specific" is another issue.

> Thus there is no distinction between a '*' subtag and an
> empty or missing
> subtag.  Syntactically, we need the ability to write '*' in the first
> (language) position for two reasons:
...

Yes, but the question is: should "*" _in general_ (disregarding the
syntactic issues) be different from "missing" or not for the "extended"
scheme (they are already for the basic sceme)

> 	the tag (not subtag) "" means "no language", not "totally unspecific
> 	language" (this is an extension to RFC 3066bis used in XML)

Hmm, seems to me that "" should (for that case) be added as another
value (for the c.p.o.), and that "*" < "". Should "" not be less than
anything?
But I'm not at all sure what "no language" is supposed to mean different
"totally unspecific language".

> 	two-letter tags mean different things depending on whether they
> 	are initial or not -- "uk" is unrelated to "en-uk".
>
> > Is it reasonable to require -sbtgps to be non-empty? Should -sbtgps
> > really be allowed to be more than one subtag (incl. *)?
>
> Once the above ambiguity is dealt with, one can take apart any valid tag
> into its four components (or more in later RFCs) unambiguously.

The division into four components is (formally) only a matter for
the scored filtering; it has no influence at all for the other schemes.

> > With the prefix matching rule here we have e.g.:
> >
> > 	ln-* < ln < ln-Srpt
> >
> > but without it we still have (e.g.):
> >
> > 	ln-* < ln  and ln-* < ln-Srpt
> >
> > but not
> > 	ln < ln-Srpt
>
> If "ln-*" is dropped in favor of just "ln", then the two
> rules agree nicely.

If you really want "ln-*" = "ln", "ln-*-vrnt" = "ln-vrnt", then we
should remove the redundant "*"s from the syntax for the extended
scheme. But that does not seem all that logical if you also want
"*" < "" rather than "*" = "" (for XML)...

> > Should we really include the prefix matching rule for the
> > case where there is a more explicit way of saying "prefix match"
> > (star at the end)?
>
> Yes, for backward compatibility (it is the rule of HTTP 1.1).

That holds for the basic scheme, which is taken from the HTTP spec.
It does not necessarily influence the extended scheme. That it is
*currently* called "extended" does not necessarily mean that the
rules have to be an extension of basic rules. One may well require
that patterns for the "extended" scheme be more explicit.

> > Again I guess primary language subtags that have a
> "suppress-script",
> > should have that script subtag inserted, if there is no explicit
> > script subtag, before comparisons.
>
> That's not required for prefix-matching, fortunately.

If "suppress-script" has no semantics, what good is it? It does mean
"please don't write it", but that is a strange recommendation if it is not
really "you needn't write it, we'll assume it if you don't".

		/kent k

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

---

From: John Cowan <[email-masked]>
Date: Tue, 14 Feb 2006 08:42:53 -0500

> scheme (they are already for the basic sceme)

But only accidentally, due to the limitations of the basic scheme.

> value (for the c.p.o.), and that "*" < "". Should "" not be less than

To be clear: the empty string is not valid RFC 3066bis either as a tag or as
a pattern, and I don't propose that it should be.

In any case, the pattern "*" is inherited from RFC 3066 and HTTP, and can't
be changed now.

> "totally unspecific language".

It means that the content is not linguistic in nature: it is a picture,
or Perl code, or stock price tables, or the like.  This is important in the XML
context, where embedding of these things in linguistic content is common.
Thus the definition of xml:lang in the latest edition of XML 1.0 says that
it must be either a language tag per RFC 3066 or its successors, or else
the empty string.

> "*" < "" rather than "*" = "" (for XML)...

If the xml:lang is "", then language-tag matching is irrelevant.

> that patterns for the "extended" scheme be more explicit.

I'll have to give the draft another close reading before I can comment on this.

> really "you needn't write it, we'll assume it if you don't".

The basic scheme can't (again for backward compatibility reasons) do that.

-- 
John Cowan  [email-masked]  www.ap.org  www.ccil.org/~cowan
   There was an old man                Said with a laugh, "I
     From Peru, whose lim'ricks all      Cut them in half, the pay is
       Look'd like haiku.  He              Much better for two."
                                             --Emmet O'Brien

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 14 Feb 2006 15:28:36 +0100 (CET)

> In any case, the pattern "*" is inherited from RFC 3066 and HTTP, and
> can't be changed now.

I'm not suggesting to change it. At least not for the "basic" scheme.

> If the xml:lang is "", then language-tag matching is irrelevant.

Hmm, I'm not so sure. You may have different language captions/subtitles,
or (audio?) commentary for things like pictures and video clips,
which are (or very much should be) otherwise the same. So the data "type"
per se does not preclude language tagging&matching.

      /kent k

---

From: Mark Davis <[email-masked]>
Date: Tue, 14 Feb 2006 07:40:56 -0800

I don't know why the discussion of total or partial ordering came in. I 
fail to understand the purpose or relevance to the topic of filtering or 
lookup.

Mark

---

From: "Kent Karlsson" <[email-masked]>
Date: Tue, 14 Feb 2006 17:05:26 +0100 (CET)

> I don't know why the discussion of total or partial ordering came in.

...partial, mostly; only upwardly closed subsets in the basic case
have a total order.

> I fail to understand the purpose or relevance to the topic of filtering
> or lookup.

In order to give a semantics for "filtering" and "lookup" that does
not consist solely of more or less vague expressions in English, but
more precisely formulated ("mathematical" if you like).

>From my first email on this thread:

|	Lookup(S, p) = sup({x in S | x <= p})

and

|	Filter(S, p) = {x in S | x >= p}

And their generalisations to (non-empty?) priority lists.
Those definitions use the partial orderings (basic and
extended) defined on tag patterns.

             /kent k

---

From: Mark Davis <[email-masked]>
Date: Tue, 14 Feb 2006 09:42:23 -0800

But there has to be some sort of reason to believe that any particular 
mathematical construct is relevant to the goals; that hasn't been 
established.

Mark

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 14 Feb 2006 21:35:35 +0100

Mark Davis wrote:
 
> there has to be some sort of reason to believe that any
> particular mathematical construct is relevant to the goals;
> that hasn't been established.

Admittedly Kent lost me with his reasoning, I didn't try hard
enough to get his points.  For the "embedded star" alternative
I'd still like to see an example where that's clearly not the
same as "unspecified subtag" for either filtering or matching.

Unrelated, mathematical constructs aren't unimportant for the
goals.  I felt comfortable with the old original concept of a
"distance metric" in four dimensions (John's 8-4-2-1 proposal).

Since we have five dimensions with (in theory) an arbitrary
number of variants I'm unsure about the term "metric".  That's
a known mathematical term, it has certain properties, and they
built complex theories like integrals on top of it.  

But it's almost three decades that I last knew (or rather I was
supposed to know ;-) the details, all I can say without reading
books I didn't touch in this millennium that I'm unsure about
our five-dimensional case, where arbitrary numbers of variants
could in theory trump anything (region, script, language).  Bye