Re: [Geopriv] Re: Last Call: 'Location Types Registry' to Proposed Stand

Hi! Harald,
We fully agree on this. But I see you are fighting here the same 
difficulty I fight against you for languages. They propose words in 
their language context as you propose languages tags in your 
internationalised context. They do the same layer violation as you 
do. The only solution to this is to conceptualise and to universalise 
the concept. ISO 11179. You define a concept, give it a unique ID 
(building a referent) and as many names as you need which name the 
concept, not its version in a given context. However I agree 
JTC1/SG32/W2 has not yet addressed the multilingual and the networked 
aspects. But IETF have clumsily approached it with IDNA and very well 
with the DNS.
The problem is that the whole process has to be "multiterative". When 
you consider your "internationalization", the concept named in 
English is to be adapted into the locale culture which tries to 
understand your concept the same way as you do (this is monologue). 
This is workable but gives leadership (and economical, cultural, 
political, technical advantages to the American end). Better you have 
a true dialog where the American concepts includes the other end's 
concepts. Unicode very partly does that for texts items.
"multinationalisation" calls for the concept to be equally understood 
(what does "understand" mean?) the same way between every cultures 
(every ends are equal). Either because the concept is truly 
universal. Or because you built all the cross-national in-between 
extended services to permit a polylogual relation. This means that 
when an American end says "kitchen", the French end will receive 
"American style Kitchen" (our kithens are not _built_ the same way 
and do not include the same set of things).
I take a very common example. Many languages have the same term for 
blue and green and only consider them as different shades. Recent 
studies shown that people of different languages describe the 
different variations of blue/green the same way with the right eye 
(left brain) but differently with the left eye (right brain), 
depending on the language.
A friend of mine works on dictionary about kids: the way kids 
understand the same thing around the world. Example: "bring me some 
water" implies many different things to do if the kid lives in a 
flat, in a farm, in a desert, in the USA, in Bangladesh, etc. and the 
water may be very different.
Welcome in multinationalisation and DRS preparatory work. BTW IAB 
will say if this is an IETF matter or not.
jfc


At 14:15 19/01/2006, Harald Tveit Alvestrand wrote:
> [taking out the iesg from CC list, but leaving WG and ietf list in]
>
> --On onsdag, januar 18, 2006 22:49:27 -0500 Henning Schulzrinne 
> <hgs(_at_)cs(_dot_)columbia(_dot_)edu> wrote:
> > Some additional comments on closer reading and a general comment:
> > > 2) Inadequate context for use:
> > >
> > > The document does not make reference to RPID, except in
> > > "acknowledgement". Thus, it has to be interpreted as stand-alone,
> > > and must contain its own guidance. RPID states:
> > >
> > >
> > >
> > > These things guide the usage of place-types in RPID, but cannot be
> > > found from the registry document.
> > Since usage will strongly depend on the context and since this  registry
> > is not limited to RPID, I think this would belong into RPID  (or other
> > documents), not the registry.
> Sigh.... I guess we disagree on principles here pretty strongly.
>
> I think that in order for a vocabulary like this to be useful, it 
> has to fit its purpose. A vocabulary that is made to fit multiple 
> purposes will in the end fit neither - for one recent example, see 
> the discussion between the "mail folks" and the "RTP folks" over the 
> proper registration and meaning of MIME content-types.
> You're defining the vocabulary now, and have the chance for 
> establishing a reasonable context. Once it's being used for two 
> purposes with conflicting requirements, it's too late to fix it.
> > > This document SHOULD give guidance for usage, saying at least:
> > >
> > > - whether it's intended that several of these values can be used
> > > together
> > I'd assume yes, in general, but defining that seems to be the role of
> > the protocol using these elements, not a registry.
> >
> > I think of the registry like a dictionary. A dictionary does not  define
> > which words you can use together.
> Yes, it does. By implication, a dictionary is for a language, and a 
> language is (among other things) a set of rules on how to put the 
> words together - and it VERY strongly implies that in order to 
> understand a word's meaning, you have to look at its context.
> But it's easy to forget about the enormous amount of baggage we have 
> when considering a concept like "word", and that there's so little 
> baggage attached to a label type like this one.
> > > - whether it's intended that a sequence of location types gives a
> > > progressively more precise set of terms (in which case
> > > internationalizing the last type you understand is appropriate) or
> > > names an intersection of the classes (in which case you would have
> > > to internationalize all of them).
> > There is no implication of hierarchy. In general, this seems  difficult
> > to achieve since not all location types are hierarchical.  For example,
> > an airport might contain a bank or a shopping-area, but  that does not
> > make either a subcategory of an airport.
> Good - then say so!
>
> > I also don't understand the need for I18N, since these are tokens  that
> > would be translated by a local application, not rendered to users.
> My mistake - this should have been "localize".
>
> To illustrate: In the flat case, "restroom, cafe, airport" could be 
> localized as "Toalett, <ukjent sted>, Flyplass" in Norwegian if the 
> application doesn't know the translation of "cafe"; in the 
> hierarchical case, one could imagine "McDonalds, cafe, eating-place, 
> public building, indoors" - it would be OK to localize that as 
> "Spisested" if "cafe" isn't known.
> > > - whether having a text string alongside it (the "note" above) is a
> > > recommended practice.
> > That's again an RPID issue. Not every protocol using these tokens  will
> > have notes.
> There's no second protocol at the moment, so you have the chance to 
> provide guidance...
> > > It MAY be appropriate to say something about field of use, like
> > > RPID does ("what types of communication is appropriate" would lead
> > > one to distinguish between "driving a car" and "passenger in a
> > > car", while one could imagine that other usages might want to
> > > distinguish between "expensive restaurant" and "cheap restaurant").
> > We are not trying to define a service location protocol that  describes
> > numerical properties of locations. I don't know how to rule  this out by
> > legal wording; presumably the expert reviewer can make  common-sense
> > judgement.
> Legal wording isn't what I'm looking for. Hints to the reviewer 
> about what the WG considers "common sense" would be helpful.

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf