Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
danbri opened this issue Sep 29, 2015 · 6 comments
Closed

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

danbri opened this issue Sep 29, 2015 · 6 comments

Comments

@danbri
Copy link
Contributor

@danbri 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 added a commit that referenced this issue Sep 29, 2015
Also updated releases.html for this, and to note that branchCode has been OK'd by Steering Group and is queued for release.
@danbri
Copy link
Contributor Author

@danbri danbri commented Sep 29, 2015

@mfhepp
Copy link
Contributor

@mfhepp mfhepp commented Sep 29, 2015

+1

@chaals
Copy link
Contributor

@chaals chaals commented Sep 29, 2015

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

@scor
Copy link
Contributor

@scor 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
Copy link
Contributor Author

@danbri 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
Copy link
Contributor Author

@danbri danbri commented Nov 6, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.