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

[JMesserly]

I am posting this to the microformats-new list because it may include
a scenario not anticipated by the current spec.  If not please forward
to the appropriate list.

Problem: on Wikipedia and on Commons (the image repository for all
wikipedias of all languages), we have historical images that we can
provide some semantic adr information on.  For example, consider the
following painting by Monet:
http://commons.wikimedia.org/wiki/File:Claude_Monet_-_The_Highway_Bridge_under_repair.jpg.
  We don't have a street address, but we know it is in the Paris
suburb of  Argenteuil.  As I understand from the hcard docs on
microformats, the canonical thing is to indicate Paris as the locality
and not pass Argenteuil.   That eliminates precision, because now (via
Operator click) Google takes me to Paris central, not the Argenteuil
neighborhood. The workaround of making Argenteuil a street address
might work except that is that there is no way of knowing that "Paris"
is a city, and presumably ineligible from being placed in any property
other than locality.  The only knowledge we might have is a placename
hierarchy: that Argentuil is part of Paris , and Paris is part of
France (up to 7 layers of meronym nesting).   Placename values are
anything that Google/Yahoo/Mapquest might recognize: a landmark like
arc de triomphe, a structure like empire state building, or a street.
In all cases, we don't know the property type of these names (that one
is a street-address, another a locality or whatever)   I have come up
with many variant solutions, but they boil down to two separate
approaches:

Solution 1: Use Locality.  In an earlier version of this, the Template
would emit   Argenteuil, Paris in the locality value.   This diverges
from adr guidance, but there is some basis for this use since X520 is
permissive in its definition of locality: "The Locality Name attribute
type specifies a locality. When used as a component of a directory
name, it identifies a geographical area or locality in which the named
object is physically located or with which it is associated in some
other important way."

 Solution 2: declare Adr type=mapsearch:  This approach is divergent
from current adr guidance on microformats.org. Oftentimes, Commons can
provide a geographic set hierarchy (meronymy).  For example, we may
know the picture is of a plaza in a neighborhood, of a borough, of a
city, of a state.  We can provide this containment hierarchy, knowing
that the square is part of neighborhood and so on, but the problem is,
we don't know these placenames are regions, cities, counties, informal
landmarks or none of the former.  Rather than jam them all into
locality delimited by commas, another approach keeps them cleanly
distinct in an array.  However this diverges severely from current
spec to do this. As of the date of this writing, the current running
version places each element in a street-address since it allows
multiple declarations, and because map applications like google, and
yahoo interpret the sequence as a containment hierarchy (example see
vcard emitted for fn= Argenteuil).  The rationale is that addresses
used by Postal workers are not the only legitimate way of locating
places.  Just as people nowadays more often tell people how to find
things via google searches rather than URLs, it is possible to give
addresses via map search expressions.  EG: meet me next year on St.
Patrick's day at Bailie's Bar‎ in Christchurch,New Zealand.  Either
google maps or Yahoo will find that just fine with that metadata, but
only with certainty if the semantics of the containment hierarchy is
expressed somehow.  It is implicit with commas in locality.  It is
less subject to ambiguities if it is permissible to encode them as
search terms by overloading the street-address field with these
values, and declare an adr type like mapsearch.  That's your
bailiwick- I don't really have a preference, the current
implementation has no special status- it is just the last one I wrote
up.  My goal is to provide Commons users the microformats based
feature of interoperability with Google/Yahoo/Mapquest and would like
to be a good citizen and do this in the supported way if possible.
The only thing I'd have a hard time with is that if contributors will
be required to explicitly encode place types (because as a practical
matter they won't do it), or if the map searches are less precise than
they could be because there is a prohibition on transferring
additional location information that commons has on an image.

 There is no urgency to this inquiry, and I am not requesting changes
to your specifications.  I would however appreciate some guidance,
however informal/provisional, and I totally understand if your
consensus is that the guidance be given with the caveat that your
advice could change in the future.  The template can easily be
alterred to emit in either of these forms and possibly others
depending on your community's recommendations.

Regards, John JMesserly