RE: Civic Address for V2

There's a compromise somewhere in the tradeoff between richness and simplicity.

A richer format has a cost, but that cost has proven (in my experience) to be necessary to accommodate all applications.  If you are developing an application for parcel delivery, then you have two stages that reduce the complexity of the richer schema to a manageable scope:

 - application profile : you don't need to know certain fields to get a parcel to someone, so don't include those.  For instance, although Landmark might be useful on occasion, you might choose not to use it to reduce complexity.

 - localization : some fields just aren't used, others can be sensibly collapsed.  In the US "N Seymour Ave" is fairly clear.

From there, you might find that it's not that complex.  As a matter of fact, for the US at least, you've probably just arrived at the format you are used to already.

No need for anyone here to specify transformations.  Those are specific to both application and localization.  If all the site wants is an address label, that's easy.  String concatenation is your friend.

Cheers,
Martin

> -----Original Message-----
> From: public-geolocation-request@w3.org [mailto:public-geolocation-
> request@w3.org] On Behalf Of Andrei Popescu
> Sent: Tuesday, 10 March 2009 2:22 PM
> To: Marc Linsner
> Cc: public-geolocation@w3.org
> Subject: Re: Civic Address for V2
> 
> Hi Marc,
> 
> On Fri, Mar 6, 2009 at 8:51 AM, Marc Linsner <mlinsner@cisco.com>
> wrote:
> > Andrei,
> >
> > You are (almost) correct in your analysis.  ;^)
> >
> > Prior to being comfortable, I would ask that you investigate the
> civic
> > location addressing enabled in Microsoft products as to it's usage
> for
> > worldwide location applications, ie. parcel delivery, public safety,
> etc.
> >
> > My basis for questioning is simply the variations that have been
> proposed to
> > the IETF.  If folks have issues with the extensive pidf-lo, is the
> proposed
> > simpler LO going to fit the bill?
> >
> 
> 
> That is a good question. In the case of parcel delivery I have yet to
> see a form that requires me to fill in 19 different fields. I have
> used quite a few Web sites for shipping stuff to various parts of the
> world and, based on this limited experience, it seems like the format
> we proposed would fit the bill. Are you thinking of a particular
> counter-example?  As for public safety, I agree with Alec: it should
> not be the main target for this API.
> 
> >
> > So, Public Safety was forging ahead with the complete acceptance that
> their
> > 'MSAG' location was different from human consumable civic locations.
>  They
> > came to the IETF and asked for an object to carry their MSAG
> location.
> > After examining the varying methods a host will discover and use it's
> > location, carrying the MSAG object plus the human consumable object
> just
> > makes no sense.  Hence, convergence.
> >
> 
> Ok, perhaps convergence is the right path in case of the IETF spec and
> for implementers of that spec. On the other hand, this is a Web API
> that's meant to satisfy a different class of use cases, which are all
> fine with a simpler format.
> 
> > So I wonder, do you believe that you can algorithmically 2-way
> transform
> > pidf-lo objects to W3C location objects with 100% success, or are you
> asking
> > hosts to carry around two different location objects?
> >
> 
> I think it's fine to live with a 1-way transformation (from pidf-lo to
> W3C) and accept the fact that the public safety use case may find our
> simpler address format inadequate. If the API is extensible, we can
> always add more fields if application developers complain.
> 
> Thanks,
> Andrei
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

Received on Tuesday, 10 March 2009 03:45:56 UTC