We have always said that we expect the unexpected (in the sense of accepting textual alternatives to structured content). Often when the textual version is particularly common or useful we document that expectation more explicitly. I think we should do that with 'address', to support publishers with under-structured address field data.

From http://schema.org/docs/datamodel.html

While we would like all the markup we get to follow the schema, in practice, we expect a lot of data that does not. We expect schema.org properties to be used with new types. We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string. In the spirit of "some data is better than none", we will accept this markup and do the best we can.

In the case of the 'address' property and PostalAddress type, a simple change would address the common usecase of unstructured "address string" data which is not partitioned into the tidy fields expected on PostalAddress. There are also address-related usecases like "room number" which are not currently anticipated in any of the PostalAddress properties (see #545).

Proposal: we add "Text" as an expected type of 'address'

Implemented, documented and queued at http://sdo-phobos.appspot.com/address

see http://sdo-phobos.appspot.com/docs/releases.html#sdo-phobos

+1

+1 (addresses are really hard... almost as hard as names…)

I agree with this change, but at the same time, based on the quote from http://schema.org/docs/datamodel.html, pretty much all properties from schema.org should have Text added as range to express the fact that search engines will use whatever data they get. Now, adding Text to every property would blow up the property tables on schema.org, which would not be a good idea. I'm sorry I don't really have a better idea to put forward here, but I'm curious where we will draw the line.

I'll jump in first and ask that we also add Text as range for the location property, which is often used with a textual address as shortcut, for example in the context of events.

@scor - I think it is worth sometimes being explicit about 'Text', when there's a common pattern. It is very very common for people to have address and location data all mushed up into a single field, so I think they both make sense. Can you file an issue for 'location'?

Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all. This includes 'location' allowing Text values.