[uf-new] Re: Exposing place names whose property type (street-adr, locality...) is unknown

[Brian Suda]

On 2/2/09, JMesserly <swarmers at gmail.com> wrote:
> It's a street name, visible in the Pearl harbor bombing run photo that
>  the link points to.  [...]  In a
>  subsequent Bot pass, Teal St. would be identified with a type that
>  would allow the template to expose it in a street-address property
>  (assuming that is the correct type for a street name without a street
>  number).

--- ah, OK, sorry, i completely missed that this is a Bot guessing at
structured data.

> Wikipedia and Commons are not a structured databases, and although we
>  can make templates that require such declarations, the contributors
>  are volunteers and generally shun bothering with formal declarations.
>  So we don't know the types of these strings.  A bot can guess at them,
>  but in some cases it will be impossible to figure out.
>  ...
>  If so, then I can code it up that way and run some bot passes so we
>  can do a volume test of a couple hundred (later thousands) of pages in
>  this form.  Naturally, such processing can be reversed so we can back
>  out if your community wants to modify this guidance.

--- this is another kettle of fish then. I guess there is two houses
of thought on this.

1) If they user didn't explicitly state the structure then you
shouldn't mess with it. Is it better to have some false positives and
more data, or less data, but have it be more correct? In this case,
the bot shouldn't add anything.

2) The other idea is that if it looks like a duck, quacks like a duck,
then it's a duck. Would attempt to make anything that looks like an
ADR into an ADR.

You are attempting #2 and trying to minimize any false-positives.

OK, i think we're on the same page now. There is a LABEL property in
vCard for a "label" representing an address. This is unstructured, and
therefore probably not much use when it gets fed to external
applications like Operator to a Map.

The vCard RFC says:

The structured type value corresponds,
   in sequence, to the post office box; the extended address; the street
   address; the locality (e.g., city); the region (e.g., state or
   province); the postal code; the country name.

It gives an example of what "locality" could mean (e.g. city) but
doesn't discount what it can't be. The same for 'street-address' it is
not explicit about that it MUST have a number or if just the
street-name would suffice. The only other sort of "catch-all" is
'extended-address'.

I personally would probably use 'extended-address', but that would be
just personal preference. (partly because an importing app like
Outlook might not accept multiple locality "cities" and drop one,
whereas the chance of extended-address colliding with others is very
low) The important part would be to get the data into the customer's
address book, then they can easily copy-paste-CrUD as needed.

i hope this helps,
-brian

-- 
brian suda
http://suda.co.uk