W3C home > Mailing lists > Public > public-geolocation@w3.org > March 2009

Re: Civic Address for V2

From: Richard Barnes <rbarnes@bbn.com>
Date: Tue, 03 Mar 2009 16:52:54 -0500
Message-ID: <49ADA6B6.4040507@bbn.com>
To: Ian Hickson <ian@hixie.ch>
CC: Marc Linsner <mlinsner@cisco.com>, Doug Turner <doug.turner@gmail.com>, Alec Berntson <alecb@windows.microsoft.com>, "public-geolocation@w3.org" <public-geolocation@w3.org>
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.  Shoving those in fields with other meanings removes 
the whole utility of semantic tagging -- you may as well just use a 
single field.

If you need examples, there are more (from Austria) in this document:
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.


Ian Hickson wrote:
> On Tue, 3 Mar 2009, Marc Linsner wrote:
>> Take a look at:
>> http://tools.ietf.org/html/draft-arai-ecrit-japan-req-01
> Could you give an actual concrete example of an actual address that can't 
> be mapped to the proposed 9-field idea?
> I don't doubt that you are right, but the ID above doesn't seem to include 
> such addresses and the structures it gives use fewer than 9 fields for the 
> address, and the actual geographic addresses in that ID are similarly able 
> to fit in a 9-field address structure, so I'm not really sure I understand 
> the problem. An actual example would be of great help here.
Received on Tuesday, 3 March 2009 21:53:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:54 UTC