-
Notifications
You must be signed in to change notification settings - Fork 905
Description
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'