Subject: Re: [Ltru] Re: Preparations for smart matching

From: "Doug Ewell" <[email-masked]>
Date: Sun, 20 Mar 2005 13:45:45 -0800

With Debbie's permission, I am moving this private thread onto the WG
list, where I feel it belongs.

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

> IMVHO, you should be as succinct as possible when tagging... tag the
> item clearly... whether it is of import to you or not... tag to the
> finest detail... this can only enhance the semantic web of the future,
> end user implementation and interoperability...

I responded:

> Are these goals compatible with one another?  To me, "be as succinct
> as possible" and "tag to the finest detail" seem contradictory.
> "Succinct" usually implies leaving out details that one might consider
> unnecessary.

Debbie replied:

> Succinct, in my view, means as clearly and concisely as possible, as
> much info as you have at your fingertips... not just the info you need
> for your own purpose... think of the wider picture...

So Debbie is saying that tags with more information are generally
preferable to those with less, even if the additional information could
be considered redundant or implicit.  For instance, using the examples
from Section 2.3, "de-CH-1996" and "en-Latn-US" would be considered
preferable to "de" or ("en" or "en-US").

I can sympathize with this to some extent, if matching algorithms are
smart enough to interpret such tags properly.  The present post, for
example, is not simply in "en" but "en-Latn-US".  If I were tagging it,
I could use either tag -- or, for that matter, "en-Latn" or "en-US" -- 
and while the additional information (especially 'Latn') might be
obvious, it's not harmful.  A good matching algorithm, IMHO, should not
reject my "en-Latn-US" post when requesting "en" content.

Note, however, that this viewpoint does go against what Section 2.3 of
the draft says.  And there is no guarantee that matching algorithms will
meet my definition of "good."

Conciseness, in and of itself, really doesn't enter into this.  There's
no "short way" and "long way" of expressing the exact same thing, except
for "deprecated-alias" situations like "i-klingon" versus "tlh".

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

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

---

From: "Debbie Garside" <[email-masked]>
Date: Sun, 20 Mar 2005 22:12:29 -0000

With the greatest respect, Doug missed out the subscript that I responded to
(his response to FE) where he said:

Doug Ewell subscript:

" The presence of a variant subtag, in and of itself, really doesn't tell
much about whether the tagger considered the variation to be the most
important detail or the least."

My point is... if the information on variant subtag is available, use it...
even though you may not need it for your own purpose.  This is what I see as
facilitating, in particular, the semantic web, knowledge management,
archiving and search/query routines.  RFC 3066bis seems intent on making
tags as small as possible (am I wrong? Just my perception), whereas I for my
purposes, always want as much information as possible, split into the
tiniest of pieces, I can then include/exclude/use/concatenate in any way
required.

But then I do have a particular interest in language variants ;-)

Debbie

-----Original Message-----
From: Doug Ewell [mailto:[email-masked]] 
Sent: 20 March 2005 21:46
To: LTRU Working Group
Cc: Debbie Garside
Subject: Re: [Ltru] Re: Preparations for smart matching

-Doug Ewell
 Fullerton, California

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 21 Mar 2005 01:08:22 +0100

Doug Ewell wrote:

> For instance, using the examples from Section 2.3,
> "de-CH-1996" and "en-Latn-US" would be considered

Depends.  When I use de-CH-1996 what I mean is that after one
decade too much with US-keyboard layouts I forgot all rules
about &szlig; vs. ss in de, and what I learned in school was
de-1901, so de-CH-1996 without &szlig; is the best I can use
without too many stupid errors.

Very disappointing for speakers of de-CH, I'd never say "Velo"
instead of "Fahrrad", and I wouldn't understand de-CH audio
data.  Script Latn and orthography 1996 are irrelevant for
audio data (e.g. in a hreflang), it will never help in this
case.  Legacy software could "think" that it's something I
don't want, therefore detailed tags can be harmful.

For another example see what your UA did with your article.
The default for MIME 1.0 text/plain is us-ascii 7bit.  You
can explicitly say so or omit it, and arguably saying so is
better.

But your UA claims that it's using utf-8 7bit.  I know that
this is the same as us-ascii, but my UA doesn't know utf-8
at all, it's just a piece of software and can't think.

Fortunately they made it very robust (= stupid), with the
correct result in this case of utf-8 7bit.

> The present post, for example, is not simply in "en" but
> "en-Latn-US".

For Unicode mentioning the script makes sense, but for 8bit-
charsets it should be implicit, excl. transliterations for
the moment.

For existing RfC 3066 software en-Latn-US is gibberish.  If
this software is a spellchecker it would be forced to guess
which en you want.  If it picks en-GB then en-Latn-US was a
bad idea.

That's why I want default scripts and a SHOULD NOT for cases
like en-Latn-*.  The recommendation to tag wisely is a waste
of time for software, it can't think.  It doesn't know what
audio data is, and if it tries it could fail miserably for
captions in video data.

> the additional information (especially 'Latn') might be
> obvious, it's not harmful.

It can be harmful.  No RfC 3066 software knows it.  It wastes
the available space for RfC 2231 "phrases" in header fields.

                        Bye, Frank

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Mon, 21 Mar 2005 00:12:27 +0100

>But then I do have a particular interest in language variants ;-)

Dear Debbie,
I am not sure your interest is "particular" (this is a need in my case) in 
the finest granularity. Could you document your need better?
Do you think there could be alternative, for example a primary tag refering 
to a secondary tag which could be called on demand? Or would you be 
interested in the subtag's semantic supporting several 
orthogonal/complementary tokens?
I would also be interested if your request corresponds to the qualification 
(for exemple in a reading) or the definition of the language (for example 
in a web service).
Thank you.
jfc

---

From: "Debbie Garside" <[email-masked]>
Date: Mon, 21 Mar 2005 09:50:17 -0000

Hi

My interest is that I am currently writing a Committee Draft (CD) for the
proposed ISO 639-6 which covers language variation (written/spoken/signed)
and provides a meta-model for an object orientated Language Description
Framework (or language registry perhaps). 

Debbie

-----Original Message-----
From: JFC (Jefsey) Morfin [mailto:[email-masked]] 
Sent: 20 March 2005 23:12
To: Debbie Garside; 'Doug Ewell'; 'LTRU Working Group'
Subject: RE: [Ltru] Re: Preparations for smart matching

At 23:12 20/03/2005, Debbie Garside wrote:
>even though you may not need it for your own purpose.  This is what I 
>see as facilitating, in particular, the semantic web, knowledge 
>management, archiving and search/query routines.  RFC 3066bis seems 
>intent on making tags as small as possible (am I wrong? Just my 
>perception), whereas I for my purposes, always want as much information 
>as possible, split into the tiniest of pieces, I can then 
>include/exclude/use/concatenate in any way required.
>

Dear Debbie,
(for exemple in a reading) or the definition of the language (for example in
a web service).
Thank you.
jfc

> > finest detail... this can only enhance the semantic web of the 
> > future, end user implementation and interoperability...
>
>I responded:
>
> > "Succinct" usually implies leaving out details that one might 
> > consider unnecessary.
>
>Debbie replied:
>
> > much info as you have at your fingertips... not just the info you 
> > need for your own purpose... think of the wider picture...
>
>the draft says.  And there is no guarantee that matching algorithms 
>will meet my definition of "good."
>
>no "short way" and "long way" of expressing the exact same thing, 
>except for "deprecated-alias" situations like "i-klingon" versus "tlh".
>
>-Doug Ewell
>  Fullerton, California

---

From: John Cowan <[email-masked]>
Date: Mon, 21 Mar 2005 09:37:25 -0500

> Framework (or language registry perhaps). 

I think it worth mentioning that there is no ISO 639-6 on the current
programme of work of ISO TC 37 / SC 2.  (My reference in an earlier
posting to ISO/IEC JTC 1 was a mistake, and should be disregarded.)
So at the moment Debbie's draft has no official status with ISO.

ISO 639-4 (general principles) and ISO 639-5 (codes for groups of
languages) are in progress, but are irrelevant to RFC 3066bis.

-- 
How they ever reached any  conclusion at all    [email-masked]>
is starkly unknowable to the human mind.        http://www.reutershealth.com
        --"Backstage Lensman", Randall Garrett  http://www.ccil.org/~cowan