Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Explicitly expect Text as possible value on 'address' #808
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.
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'
added a commit
Sep 29, 2015
This was referenced
Sep 29, 2015
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'?