Message-Id: <6.1.2.0.2.20050320235957.03f63eb0@mail.jefsey.com>
Date: Mon, 21 Mar 2005 00:12:27 +0100
To: "Debbie Garside" <debbie@ictmarketing.co.uk>,
	"'Doug Ewell'" <dewell@adelphia.net>,
	"'LTRU Working Group'" <ltru@ietf.org>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: RE: [Ltru] Re: Preparations for smart matching
In-Reply-To: <200503202213.j2KMDKnH026385@smtp-los04.proxy.aol.com>
References: <013601c52d96$2c9f2a20$030aa8c0@DEWELL>
	<200503202213.j2KMDKnH026385@smtp-los04.proxy.aol.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: 
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

At 23:12 20/03/2005, Debbie Garside wrote:
>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 ;-)

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





>Debbie
>
>-----Original Message-----
>From: Doug Ewell [mailto:dewell@adelphia.net]
>Sent: 20 March 2005 21:46
>To: LTRU Working Group
>Cc: Debbie Garside
>Subject: Re: [Ltru] Re: Preparations for smart matching
>
>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
>Ltru@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru