RE: Civic address representation in v2

I agree with Richard on this one.  There are some minor issues with the current mapping.  For instance, "city" maps to A3 in some cases, but it is often used as an A4.  This is useful in larger cities:  I can say Tōkyō (or 東京) at A3 and Chūō (or 中央区) at A4 and both pieces of information provide value.

I'll note that any mapping is likely to be a profile to some degree, unless you like really complex data models.  In particular, the flexibility offered by 5139 regarding language and script is probably more than any application is likely to want to consume.

To that end, I'd suggest that a single language tag be included.  This helps without encumbering the format too much, even though some mixed language addresses cannot be represented easily.

--Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Richard Barnes
> Sent: Friday, 20 November 2009 11:14 PM
> To: Lars Erik Bolstad
> Cc: public-geolocation
> Subject: Re: Civic address representation in v2
> 
> Hey Lars Erik,
> 
> Glad to provide some input.  First, you're correct about RFC numbers:
> RFC 5139 [1] is the latest address specification.  More properly, the
> overall list of civic address element types is maintained as an IANA
> registry [2]
> 
> I actually think that the current address structure in the working
> draft maps pretty well to a subset of the RFC 5139 syntax:
> 
> country ~ country
> region ~ A1
> county ~ A2
> city ~ A3
> street ~ POD + RD + STS + PRD
> streetNumber ~ HNO + HNS
> premises ~ NAM
> postalCode ~ PC
> 
> This leaves a couple of problems.  First, it's clearly not a
> reversible transform with the concatenation, unless you add some
> additional constraints on how those elements are put together.
> Second, you are restricted to western-style addresses, so you'll have
> trouble covering parts of Japan and China (e.g., "4 Rue Rabelais" vs.
> "7-2, Marunouchi 2-Chome Chiyoda-ku"; concepts like -ku and -chome are
> supported by the additional heirarchical elements A4-A6).
> Nonetheless, not a bad start.
> 
> If you want to append a more proper RFC 5139 object, it seems a little
> silly to use JSON in a string rather than just a JSO -- a JavaScript
> Object.  The logical format is just a list of type-value pairs, where
> the type names are from the IANA registry [2] and the values are
> strings.  This maps naturally onto a javascript object with a bunch of
> optional string fields, and it seems like you could define it mostly
> by reference to RFC 5139 or the IANA registry.
> 
> Cheers,
> --Richard
> 
> [1] <http://tools.ietf.org/html/rfc5139>
> [2] <http://www.iana.org/assignments/civic-address-types-registry>
> 
> 
> 
> 
> 
> 
> On Nov 20, 2009, at 3:29 AM, Lars Erik Bolstad wrote:
> 
> > Hi Richard,
> >
> > The Address interface attributes in the editor's draft of v2 [1] are
> > based on a proposed mapping of RFC4119 fields, where some of the
> > 4119 fields are combined into the additionalInformation attribute.
> > [2] At the recent f2f meeting we revisited this discussion and
> > concluded that we'd like to have some input from you on this. You
> > can find the relevant meeting minutes here:
> http://www.w3.org/2009/11/03-geolocation-minutes.html#item03

> >
> > First of all, it seems that RFC5139 is the one we should be looking
> > at, and not 4119. Is that correct?
> >
> > The current proposal is to expose the "raw" RFC5139/4119 civic
> > address data in the additionalInformation attribute as a string
> > containing a JSON object.
> > What are your thoughts on this?
> >
> > Thanks,
> > Lars Erik
> >
> >
> > [1] http://dev.w3.org/geo/api/spec-source-v2.html

> > [2] http://lists.w3.org/Archives/Public/public-

> geolocation/2009Mar/0027.html
> 
>

Received on Monday, 23 November 2009 23:45:10 UTC