- From: Perry Tancredi <ptancredi@quova.com>
- Date: Tue, 3 Mar 2009 15:13:07 -0800
- To: "Ian Hickson" <ian@hixie.ch>, "Richard Barnes" <rbarnes@bbn.com>
- Cc: "Marc Linsner" <mlinsner@cisco.com>, "Doug Turner" <doug.turner@gmail.com>, "Alec Berntson" <alecb@windows.microsoft.com>, <public-geolocation@w3.org>
For reference, my address in the UK was that didn't work in a two line address format was: Waterfront, 2nd Floor Hammersmith Embankment Chancellors Road London W6 9RU United Kingdom I think either Andrei's proposal or Richard's proposal would work (they are essentially the same), though I don't like the A5 mapping to Premises; it should be to CAType 25 in RFC4775 (building). I don't think either proposal would satisfy Japanese addresses without the addition of at least one more field (A4) for chou, but I'm not an expert. Even with that addition, both proposals achieve relatively few fields but still allow semantics. The trade off is separation of street details and the semantic designation of "extra" information like Floor and Room. I haven't seen agreement in the group about whether that information is necessary for all the use cases or not. Here is another address for Google's office in Amsterdam, which is a good (hopefully obvious) example of why semantics matter: Claude Debussylaan 34 Vinoly Mahler 4 Toren B, 15th Floor Amsterdam, Netherlands 1082, Netherlands -----Original Message----- From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org] On Behalf Of Ian Hickson Sent: Tuesday, March 03, 2009 2:24 PM To: Richard Barnes Cc: Marc Linsner; Doug Turner; Alec Berntson; public-geolocation@w3.org Subject: Re: Civic Address for V2 On Tue, 3 Mar 2009, Richard Barnes wrote: > > It's not really the number of fields that's important, right? If you > don't care about the semantics of the fields, then you can just use > one fields where everything's smashed together. > > The important thing about the discussion in the Japanese document is > that Japanese addresses require substantially different *semantics* > than western addresses. How is the following mapping incorrect? > you may as well just use a single field. That might not be a bad idea, actually. What's the use case for having the information in multiple fields rather than just a multiline field? > the whole utility of semantic tagging -- What is the utility in this case? > If you need examples, there are more (from Austria) in this document: > <http://tools.ietf.org/html/draft-ietf-geopriv-civic-address-recommendat ions-02> Address: 1234 Musterstadt, Hauptstrasse 1a - 5a Block 1b Haus 2c Stiege 1 Andrei's proposal country region county city Musterstadt premises 5a Block 1b Haus 2c Stiege 1 street Hauptstrasse street number 1a details postalcode 1234 Address: 6173 Oberperfuss, Riedl 3097 (Pfarrkirche) Andrei's proposal country region county city Oberperfuss premises (Pfarrkirche) street Riedl street number 3097 details postalcode 6173 Address: Karlsplatz 1/2/9 Wien A-1010 Austria Andrei's proposal country Austria region county city Wien premises street Karlsplatz street number 1/2/9 details postalcode A-1010 How are these mappings incorrect? > There's an example in there that uses 11 different fields in a single > address (in its original format) and 8 in the PIDF-LO format. The only > reason it uses fewer fields in PIDF-LO is that they defined an > unambiguous conversion to and from that format. Which, as I've said, > could be an option here. It's always possible to have a format that's even less ambiguous than the last, so we're always going to have a conversion step at some point, even if we reuse an address format. The question is, what is the simplest format that we can use that is still practical and addresses our use cases? Marc said nine fields wasn't enough; why not? Alex proposed a six field format that is already shipping internationally, but Perry said that it didn't work for his addresses. What exactly what the problem with it? Does the nine-field option work better? Are there use cases that a one-field answer wouldn't solve? -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 3 March 2009 23:13:44 UTC