Explicitly expect Text as possible value on 'address' #808

danbri opened this Issue Sep 29, 2015 · 6 comments


None yet

4 participants

danbri commented Sep 29, 2015

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'

@danbri danbri pushed a commit that referenced this issue Sep 29, 2015
Dan Brickley Fix to #808 - supporting Text as an expected type for address.
Also updated releases.html for this, and to note that branchCode has been OK'd by Steering Group and is queued for release.
@danbri danbri self-assigned this Sep 29, 2015
mfhepp commented Sep 29, 2015


chaals commented Sep 29, 2015

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

scor commented Oct 1, 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.

danbri commented Oct 1, 2015

@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'?

danbri commented Nov 6, 2015

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

@danbri danbri closed this Nov 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment