[Developers] [Data-modeling] Comments sought on proposed change to schema for addresses

[Scott Meyer]

Jeff Prucher wrote:

> The problems:
> 1) The mailing address type is linked to from a number of different types
> (currently 13, but this will surely grow). This means that any application
> that starts with an address (or geocode) and wants to know what's at that
> location must use /type/reflect to discover the topic and its type. And a
> separate query to retrieve all the property names and values for the
> connected Topic. 

This problem seems generic to any type with a lot of "suggested properties"
While the "any_reverse" dance is a bit awkward, it is an idiom that
can be learned.
 
> 2) There are some instances of types that it would be useful to be able to
> plot on a map, but which are exceptional enough that it doesn't make sense
> to add the address property to the type. One example of this that has come
> up is public artworks. It typically doesn't make sense to type them as
> "location", and adding an address property to the "artwork" type is somewhat
> counter-intuitive. 

I think that "making sense" is heavily context dependent.  As soon as we
have a standard "plottable" interface, which could be as vague as "having
a single property of type Location or Geolocation or being co-typed as
Location" it will "make sense" to structure data this way, because that
is what you do if you want something to be plottable.

To support funtionality like "show me anything in San Francisco" you will
have to do a bit of work to move from "geocodes in San Francisco" which
are easy to find (if we approximate SF as a rectangle), to Plottable Things
which may refer to a geocode directly or to a Location which refers to a
geocode.  Alternatively, you could structure the query the other way, make a
query to determine all "plottable" types and then look for instances of those
types in San Francisco: no "any_reverse" dance necessary, but you do have to
query the type system.

I don't think that the proposed change improves anything, other than the
need to learn the "any_reverse" dance (or to query the type system) in this
one case.

-Scott