Re: Civic Address for V2

Hello Henning,

I do not think we have any use cases that require comparing addresses  
for equality.  We clearly did not for the v1 addressing (coords).  I  
tend to think that civic addressing comparison is out of scope.  For  
example, if two UAs pass back an address for the same place, I do not  
think that we should make any guarantees that the data the UA pass  
back to the requesting site is the same.  In fact, I do not think that  
the addresses need to be the same between different runs of the same  
UA.  The reason for this is that UAs might use different back-ends for  
determining the actual location of the UA.  Maybe the first  
geolocation request uses WiFi->location, and the second request uses a  
user defined position, or what have you.

Secondly, we are not designing this API for someone like your or me or  
anyone on this mailing list that can understand thirty+ fields, have  
no problem looking up extensive documentation, and enjoy digging  
through mailing list for rationale on the way things are they way they  
are..  Rather, the API must be designed for the web at large.  I think  
we should design the simple-to-use over a can-do-everything-everyone- 
every-wanted address for v2.

Keep in mind, that one could always create a civic address spec that  
leverages the geolocation specification and implementations.  For  
example, you could add a separate civicAddress to the position object  
in a future specification.

Regards,
Doug Turner


On Mar 9, 2009, at 11:25 AM, Henning Schulzrinne wrote:

> While this is clearly a use case, clear and unambiguous presentation  
> of address elements is important for other applications, such as  
> comparing addresses for (partial) equality and proximity. In my  
> experience, dealing with clearly defined elements, even if a few  
> more, is far easier to program with than having to deal with picking  
> apart blobs of data and having to implement all kinds of heuristics  
> to deal with everybody's unique way of stuffing data into fields. I  
> don't see why these elements are hard to understand.
>
> Henning
>
> On Mar 9, 2009, at 2:19 PM, Alec Berntson wrote:
>
>> The public safety and emergency scenarios are repeatedly used as a  
>> defense for complicated CivicAddress interfaces. I agree that for  
>> those scenarios, having a very concise, unambiguous format is vital.
>>
>> I question whether a javascript browser API is actually going to be  
>> used for these scenarios. Based on the use cases in the spec, we  
>> are targeting primarily consumer scenarios where location,  
>> especially civic address location, is being used as metadata and  
>> for making web apps contextually aware.
>>
>> I don't see why this API needs to compete with or support standards  
>> that are designed for a very different set of use cases.
>>
>>
>> -----Original Message-----
>> From: public-geolocation-request@w3.org [mailto:public-geolocation-request@w3.org 
>> ] On Behalf Of Marc Linsner
>> Sent: Friday, March 06, 2009 7:51 AM
>> To: Andrei Popescu
>> Cc: public-geolocation@w3.org
>> Subject: Re: Civic Address for V2
>>
>> 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?
>>
>> Let me give you some more background of discussions around
>> location/addressing that have taken place over the years.
>>
>> The starting point of the GeoPriv civic addressing was rooted in  
>> the US
>> Master Street Address Guide (MSAG) that is under the administration  
>> of the
>> Public Safety Authorities across the US.  The MSAG is used as the
>> authoritative db for call routing and dispatch of Public Safety  
>> responders.
>> Even though the reasoning for the complete delineation of the civic  
>> address
>> into fields such as pre/post street directionals seems  
>> excruciating, those
>> in charge of trimming seconds from response time provided evidence  
>> of their
>> necessity.  Their solution handles the 71 variations of ³Peachtree²  
>> (St,
>> Blvd, Pl. etc) found in the Atlanta, GA metropolitan area without  
>> ambiguity.
>>
>> So, as the Internet handles the convergence of various  
>> applications, it also
>> has to handle the convergence of data required by those various
>> applications.
>>
>> Yes, for more than 40 years, the MSAG location has been Œdifferent¹  
>> from
>> normal human consumable locations.   It¹s unreasonable to imagine a  
>> future
>> that supports multiple descriptions/objects for the same location,  
>> as the
>> Internet has completely distilled the model where the application  
>> provider
>> is held responsible for the location of the service.  Location data  
>> will be
>> derived in a myriad of methods - host derived, end-user derived,  
>> network
>> derived and various combinations of each.
>>
>> 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.
>>
>> 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?
>>
>> Just something to think about,
>>
>> -Marc-
>>
>>
>>
>>
>> On 3/6/09 8:49 AM, "Andrei Popescu" <andreip@google.com> wrote:
>>
>>> Hi Charles,
>>>
>>> On Wed, Mar 4, 2009 at 8:42 AM, Charles McCathieNevile <chaals@opera.com 
>>> >
>>> wrote:
>>>>
>>>> So this comes back to the use cases and requirements. If being  
>>>> able to
>>>> compare addresses and make useful inferences matters, then it is  
>>>> important
>>>> to split out the semantics, with the level of detail determining  
>>>> how far
>>>> down the semantic split should go. Otherwise, you are right that  
>>>> it is not
>>>> really important.
>>>>
>>>
>>> I think you're absolutely right, this is the issue. We could go down
>>> the route of splitting semantics in such a way that the address  
>>> format
>>> has a field dedicated to every particularity of any address on Earth
>>> and satisfy all use cases from here to eternity. Or we could have a
>>> slightly more pragmatic approach of drawing the line at a level of
>>> detail that we deem reasonable in terms of complexity (i.e. easy to
>>> understand by developers and capable of satisfying the use cases we
>>> now have in the document). If we're careful to design the API in an
>>> extensible manner, we can act on feedback from application  
>>> developers
>>> and API implementers and extend the format based on their needs. To
>>> me, this latter approach is the one that we should take: start from
>>> from rfc 4119 and simplify it  (i.e. coalesce some fields and give
>>> them humanly understandable names) as I proposed. This yields a
>>> solution that is also reasonably close to what Microsoft has in
>>> products that ship pretty much everywhere, which is rather  
>>> reassuring
>>> to me.
>>>
>>> Thanks,
>>> Andrei
>>>
>>
>>
>>
>>
>>
>>
>
>

Received on Monday, 9 March 2009 18:46:15 UTC