Guidance or vocab needed regarding Real Estate (property purchase, rental etc.)

Question

Guidance or vocab needed regarding Real Estate (property purchase, rental etc.)

danbri opened this issue 10 years ago · 125 comments

Migrating in from https://www.w3.org/2011/webschema/track/issues/13

There are various pages about real estate out there, and we periodically get questions about how schema.org might be applied. How to use Offer, Product; whether additional vocab is needed, etc.

This issue tracks the general topic and potential vocabulary or documentation improvements.

Answer 1 · 2015-01-21T19:29:55.000Z

Zillow.com should REALLY get involved with this issue. Come on Zillow !
(Just sent Zillow Research a private message asking for participation again, they might contact @danbri directly)

Answer 2 · 2015-08-31T20:17:11.000Z

I'm just checking to see if there's been any further discussion on expanding the schema.org vocabulary to support more information around the real estate industry. As it stands now I see RealEstateAgent as the only real estate specific item in the vocabulary. There are several additional properties of the RealEstateAgent class that I would suggest adding, as well as creating new classes for real estate offices, real estate listings, and multiple listing services.

We're currently working with several national real estate franchisors to help create ways for them to share data with each other and their vendors. Ideally we would use schema.org as a base, potentially merging some of the schemas from reso.org, to create a full vocabulary for the real estate industry.

Answer 3 · 2015-09-01T08:56:51.000Z

First: I am in the final stage of developing an accommodation extension proposal that will also contain elements that can be used for the real estate market.

However, note that you can cover most of what you need for real estate already now:

Create a schema:Offer for the commercial aspects of the offer. Use schema:businessFunction to indicate whether the property is for sale or for lease. schema:priceSpecification allows for more granular price information; schema:price will also work.
Use schema:itemOffered to link to a schema:Residence entity that describes the apartment or house or start with the offered object and link to the offer via schema:offers.
Use schema:additionalProperty for all additional features of the real estate object that are not yet covered by schema.org.
If you want to be formally more specific about the type of building, use types from http://www.productontology.org.

In theory, both of the attached examples should work (in practice they don't as of today due to strange bugs in the Google validator):

{ "@type" : ["http://schema.org/Residence", "http://schema.org/Product"],
  "additionalType" : "http://www.productontology.org/id/Condominium",
  "name" : "Condo in NYC",
  "description" : "A great place for your family",
  "offers" : { "@type" : "http://schema.org/Offer",
               "name" : " Condo in NYC for $ 299,000",
               "price" : "299000.99",
               "priceCurrency" : "USD",
               "businessFunction" : "http://purl.org/goodrelations/v1#Sell" },
  "photo" : "http://acme-real-estate.org/offers/condo123.png"
 }


{ "@type" : "http://schema.org/Offer",
  "name" : " Condo in NYC for $ 299,000",
  "price" : "299000.99",
  "priceCurrency" : "USD",
  "businessFunction" : "http://purl.org/goodrelations/v1#Sell",
  "itemOffered" : { "@type" : ["http://schema.org/Residence", "http://schema.org/Product"],
                    "additionalType" : "http://www.productontology.org/id/Condominium",
                    "name" : "Condo in NYC",
                    "description" : "A great place for your family",
                    "photo" : "http://acme-real-estate.org/offers/condo123.png"
                   } 
 }

Answer 4 · 2015-09-01T09:29:12.000Z

BTW, we could include schema:Place in the domain of schema:offers and in the range of schema:itemOffered. This would make it more straightforward to use places in offers. But we need to think about whether we want to handle such cases via multi-typed entities or hard-wired domain/range/subtype relationships first. Proper multi-typed entity support will be cleaner and more extensible, IMO.

Answer 5 · 2015-09-01T14:06:20.000Z

Hello all,
I'm here for the same reason: enhancing Schema.org vocabulary to be able to better fit the needs of marking up Real Estate properties with all posible details.
One of the formats that needs urgent enhancement is the Residence markup and subsidiaries: ApartmentComplex, GatedResidenceCommunity and SingleFamilyResidence.

I don't know how you guys add new proposals, but I'll type them here for now. I'm referring to HTML markup implementation not JSON-LD which can concatenate 2 or more itemtypes.

All those specific markups (Residence, ApartmentComplex, GatedResidenceCommunity and SingleFamilyResidence) are missing a very important element, and that's Price.

a) no, you can't use the itemtype PriceSpecification for this purpose because, for now, Google sees it as a separate declaration - and lists it as such - instead of including it as a parameter in the main declaration e.g. within the Residence): http://screencast.com/t/v9vaaB45y
b) tried to use the itemprop="price" and the itemprop="priceCurrency" within the itemtype Residence and Google warn me that they do not belong there: http://screencast.com/t/FNz4C7XSEB6Z

A secondary important element - also missing from those markups mentioned at pct. 1) - is a markup which allows additional information about a property, respectively amenities.

a) right now, I've marked the amenities with the help of itemprop="description" and itemprop="name" to be able to fit them within the itemtype Residence, which doesn't seem the right way, but I couldn't find any better properties for them (and all subsidiaries for that matter): http://screencast.com/t/6OcLrT9BOvb4

How can we improve these?
Thanks.
Arthur

Answer 6 · 2015-09-01T14:13:39.000Z

Hi Arthur:
It is a fundamental principle in schema.org and the underlying GoodRelations data model that things do not have prices, but that instead offers including / referring to these things have prices. The same house has a very different price for rent and for sale, the same hotel room has a different price at different times, etc.

The patterns I provided are in principle correct; it is just that the Google testing tool has these days a bug, which will hopefully be fixed soon.

As for additional properties of real estate objects: There are a few properties that should indeed be added to certain subtypes of schema:Place, namely the numberOfRooms, the size, etc. For other, in particular those that are not standardized globally, using schema:additionalProperty is a sufficient pattern.

A good resource that explains the core conceptual model of schema.org for offers is here:

http://wiki.goodrelations-vocabulary.org/Documentation/Conceptual_model

Martin

Answer 7 · 2015-09-01T14:23:43.000Z

Hi Martin,
Thanks for the fast reply.

Can you please provide me a correct usage for schema:additionalProperty to be able to succesfully fit in within the schema:Residence? In this way, I might be able to implement all the amenities of a Real Estate property with this markup.

Thanks,
Arthur

Answer 8 · 2015-09-01T14:25:26.000Z

Hi Arthur,

there are plenty of examples at the bottom of http://schema.org/PropertyValue (I will add a pull request to make them appear at additionalProperty, too).

Answer 9 · 2015-09-01T15:36:16.000Z

Hi Martin,
Your proposed method It's working great, it validates all the amenities implemented with schema:PropertyValue: https://www.diigo.com/item/image/3v9ds/6okx

As for the Google Rich Snippet Testing Tool, to what bug do you refer, regarding listing the price with schema:PriceSpecification outside the Residence itemtype http://screencast.com/t/v9vaaB45y OR for using the itemprop="price" and the itemprop="priceCurrency" within the itemtype Residence, Google returns an error that they do not belong there: http://screencast.com/t/FNz4C7XSEB6Z?

Thanks for the tips.
Arthur

Answer 10 · 2015-09-02T14:53:15.000Z

Hi guys,
I need a little bit of help again:

I can't seem to find a correct implementation for a price of a Residence with the schema:PriceSpecification:

the problem seem to be related to the itemprop attribute from within the main declaration:
itemprop="priceSpecification" itemscope= itemtype="http://schema.org/PriceSpecification"

no matter what value I assign to the respective itemprop (either "priceSpecification" or "totalPrice" etc.) I can't get it correctly integrated, Google Rich Snippet Testing Tool return me an error as it's not recognized by Google as an object for type Residence: http://screencast.com/t/WjxVjtYfCah1

What do I do wrong? What itemprop attribute fits in there?
Thank you.
Arthur

Answer 11 · 2015-09-02T14:55:21.000Z

As I tried to explain, you have to attach the priceSpecification property to the offer, not to the residence.

Answer 12 · 2015-09-02T15:01:10.000Z

Here's an example of what Martin means:

Some residence $5,908,000

2015-09-02 16:55 GMT+02:00 Martin Hepp notifications@github.com:

As I tried to explain, you have to attach the priceSpecification property
to the offer, not to the residence.

—
Reply to this email directly or view it on GitHub
#241 (comment)
.

Answer 13 · 2015-09-02T15:04:30.000Z

Thank you guys, I'll try to implement it now in this way.

Answer 14 · 2015-09-02T15:20:14.000Z

Hi jvandriel (I'm sorry to call you on your nick-name but don't know your name),

The example you provided does not validate either, nor by itself, neither implemented in my HTML, I get even more errors than before, can you please have a look? http://screencast.com/t/3d0J26TZiSE

This is in my implementation: http://screencast.com/t/2rp8sjnjnI

Sorry for bothering, I do struggle to make it right.
Thanks,
Arthur

Answer 15 · 2015-09-02T15:37:22.000Z

Unfortunately those errors have nothing to do with the validity of the
markup.

Google's validator has a bug that it doesn't recognize multi type entities

a bug that should have been fixed a long time ago already.

And as for the missing 'price' warning, this has to do with how Google
prefers your markup. The 'priceSpecification' is a property they still
don't look at for their rich snippets, even though it is perfectly fine to
use it as such.

I suggest you use the Structured Data Linter if you want to know if your
markup is correct as it doesn't take any particular search engine prefered
markup into account but solely looks whether your markup is correct
according to syntax rules - http://linter.structured-data.org/

Ps, my name is Jarno ;)
On Sep 2, 2015 5:20 PM, "ChiefRA1" notifications@github.com wrote:

Hi jvandriel (I'm sorry to call you on your nick-name but don't know your
name),

The example you provided does not validate either, nor by itself, neither
implemented in my HTML, I get even more errors than before, can you please
have a look? http://screencast.com/t/3d0J26TZiSE

Sorry for bothering, I do struggle to make it right.
Thanks,
Arthur

—
Reply to this email directly or view it on GitHub
#241 (comment)
.

Answer 16 · 2015-09-25T13:51:53.000Z

I have just closed #571 as a duplicate of this issue. If you didn't see it already, please take a look over the discussion there.

Answer 17 · 2015-10-09T10:20:19.000Z

Thanks Jarno.

@danbri Dan do you have any ideea when Google Structured Data Markup Tool will recognize and support multi type entities?
The Real Estate can't be marked up correctly without them and we're striving to do things right :)
Thanks.

Answer 18 · 2015-10-09T13:29:21.000Z

@ChiefRA1 - I have no ETA on that, but let's keep schema.org's issue tracker focussed on schema.org rather than the products of related companies. Thanks!

Answer 19 · 2015-10-09T15:31:17.000Z

Sure @danbri , through "Real Estate" I didn't mean any specific companies products, but the "Real Estate Properties" products in general, focusing on marking them up correctly through schema.org markup and being able to verify the markup with Google's Tool.
Thanks.

Answer 20 · 2015-10-09T15:44:19.000Z

@ChiefRA1 oh, I was just referring to http://developers.google.com/structured-data/ not properly supporting multiple-typed entities. Discussing real estate schemas is perfectly in scope here. And yes it would be nice if SDTT made it easier.

Answer 21 · 2015-10-11T11:07:05.000Z

@ChiefRA1 @danbri Note that my hotel extension proposal (available soon) will also improve the vocabulary for real estate - number of rooms, description of rooms, floor sizes, amenities, etc.

See current draft at e.g. http://sdo-hotels.appspot.com/House

But yes, we need support for MTEs for this an other use-cases.

Answer 22 · 2016-02-22T23:07:35.000Z

The Real Estate Industry has been moving to a standard called RESO. I think it would be great if any schema names can match the reso standards:

You can view the standard by downloading the data dictionary (v1.4):
http://www.reso.org/download-access

Answer 23 · 2016-02-23T08:52:07.000Z

https://reso.memberclicks.net/assets/docs/reso%20eula.pdf is a poor fit for what we would need here. For example "Except as expressly provided in this EULA, End User may not reproduce, distribute, or display the RESO Product" and the entire "End user obligations" section do not seem well suited for use in schema.org-like projects. But let's not have a legal documentation interpretation thread here. The work is clearly relevant and we could explore mappings, or some more active kind of collaboration (with more appropriate terms) if they are interested. Anyone have contacts?

Answer 24 · 2016-02-23T10:54:02.000Z

@danbri I've mentioned schema.org to someone directly affiliated to RESO before. I've tapped that contact on the shoulder again since seeing this. Worth including the other significant work in this field (that I know of), namely OSCRE which appears to have slightly more permissive copyright terms.

Answer 25 · 2016-02-23T14:47:42.000Z

I'm a RESO member and actively working on mapping RESO classes to the schema.org context.

IMO, the RESO EULA is an artifact that does not accurately reflect the organization's current mission. I had the same concern before starting my project and got the thumbs up from RESO's Executive Director, Jeremy Crawford. I will raise the EULA issue with the board and report back here.

I'll be doing a presentation on RDF and Schema.org as a model for creating data portability at the RESO spring conference in April.

Answer 26 · 2016-02-23T14:56:00.000Z

Morning and thanks for the heads up Matthew.
Dave appears to have something going in your court. If you have any questions or suggestions for the RESO dictionary, please feel free to contact me. Rob@crmls.org.
We're a flat purpose built dictionary for MLS data in the US and Canada. We've expanded beyond the MLS borders bit with the same flat structure that is so common to our industry. Let me know how I can help or if you have any questions.

Rob Larson
Chair, RESO Data Dictionary Workgroup.

Answer 27 · 2016-02-23T14:58:32.000Z

And you can email info@reso.org with questions about the EULA and acceptable use.

Answer 28 · 2016-02-23T18:44:56.000Z

Thanks @Dreyer, @dduran1967 @RobLarsonCRMLS - this all sounds very positive, thanks for the connections and enthusiasm to collaborate. I'm also copying @vholland here as the flat dictionary additions are reminiscent of some other extensions we've been discussing around local businesses.

You might also be interested to take a look at yesterday's blog post highlighting GS1's new vocabularies. Not so much for the content but for the collaborative model: they have their own schemas and workflows and organizational structures and so on, and so have opted for what we call the "external extension" approach rather than something managed within the schema.org project (like bib.schema.org, auto.schema.org).

@dduran1967 - perhaps when your mapping explorations are developed you can share them here; hopefully they will show a path that will let us explore RESO as another external extension, if we can plug it into the types, properties and offers structure of schema.org. However we are also likely to handle at least the basics of real estate within schema.org, and it would be good to document mappings to corresponding RESO terms as we do so. Having glanced at RESO it is clear that we would be unlikely to go that deep within a schema.org treatment of real estate, so figuring out how to combine the approaches makes a lot of sense. I think the recent precedent from GS1 is well with exploring.

Answer 29 · 2016-08-05T00:34:46.000Z

I see the last post here was Feb 2016, it is now Aug 2016.

Schema.org Residence, singleFamilyResidence etc still seem to be very lacking in properly describing Real Estate properties.

Any news on an update or the ability to reference the RESO system @RobLarsonCRMLS @danbri

Answer 30 · 2016-08-05T05:37:40.000Z

We have been working on hotels first. See http://webschemas.org/docs/hotels.html for the approach which is more or less complete. Real estate should follow, and re-use bits of the design as appropriate...

Answer 31 · 2016-08-05T06:01:15.000Z

I'm sorry guys, I got sidetracked on other projects and dropped the ball on this. We've got a good start on a schema.org extension and JSON-LD context for mapping RESO Property/PropertyListings and Contact/Members to schema.org. I will get this submitted here for discussion before the Fall RESO meeting!

Answer 32 · 2016-08-05T06:03:57.000Z

@dduran1967 can you take a look at the hotels/accomodation approach? another entry point is http://webschemas.org/docs/releases.html#g915

Answer 33 · 2016-08-05T06:05:38.000Z

Yes, I will @danbri

Answer 34 · 2016-08-11T12:56:50.000Z

I see singleFamilyResidence is no longer under Residence (though Apartment is) and seems to be under a new item named House.

Is House New?

If so, what is the best way to get notified of these changes?

Answer 35 · 2016-08-11T13:20:18.000Z

@ckxion yes, this was a change that came about as part of the hotels/accommodation work nearby in #915. House is new in version 3.1. If you skim #915 for "residence" you'll see various discussions there, including @mfhepp arguing that "Residence" is more of a role (connection a person to a place). We have tried to find a balance between maintaining existing vocabulary and making a structure that will allow some re-use of common patterns between the hotel/accommodation and real estate usecases.

Answer 36 · 2016-08-11T14:02:22.000Z

Are you checking what is being done at RESO? Most of real estate sales in the US and Canada are there or heading to that flat structure. Let me know if I can assist.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

On Thu, Aug 11, 2016 at 6:20 AM -0700, "Dan Brickley" <notifications@github.com mailto:notifications@github.com> wrote:

@ckxionhttps://github.com/ckxion yes, this was a change that came about as part of the hotels/accommodation work nearby in #915 #915. House is new in version 3.1. If you skim #915 #915 for "residence" you'll see various discussions there, including @mfhepphttps://github.com/mfhepp arguing that "Residence" is more of a role (connection a person to a place). We have tried to find a balance between maintaining existing vocabulary and making a structure that will allow some re-use of common patterns between the hotel/accommodation and real estate usecases.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/241#issuecomment-239158410, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQn_gIcediD511JL4sAySHqHQwamjvKtks5qeyGegaJpZM4DVNjU.

Answer 37 · 2016-08-11T14:36:12.000Z

@dduran1967 is looking into RESO mappings, see above. We'll use this github entry to coordinate...

Answer 38 · 2016-08-11T17:13:28.000Z

@danbri I realize this thread is frequented by people who know a lot more about schema than me, so I appreciate your prompt response. House/singleFamilyResidence seems interesting, I am sure I will have more questions.

I hope it is ok to ask a side question. Schema.org reports number of sites using a specific term eg House = 10 to 100. Is there any online search facility that can be used to find some of these 10 to 100?

Answer 39 · 2016-08-11T17:21:36.000Z

@ckxion we should probably have written 0-100, since new terms show up that way too. You can use Google Custom Search Engine to restrict searches to specific types, see https://support.google.com/customsearch/answer/4544182?hl=en - although the drop-down list of types may not list everything, you can just er, type in the name of the type into the box for advanced settings in http://www.google.com/cse/

For example I just made https://cse.google.com/cse/publicurl?cx=013484121852858951051:6myouq_mzxa (using my non-work google account) in a couple of minutes. It is configured to find mention of types called "Hotel". It found the following:

(it will sometimes find pages without schema.org, which may be due to changes in the site or to quirks in the tool, I'm not sure)

Answer 40 · 2016-08-12T14:45:10.000Z

@danbri Thanks for letting me know about cse.google I have searched several times for something like this without success - this will be much quicker than doing a standard Google search then checking Source.

There seems to be 102 URL's (fewer Domains) using schema House - I checked the source of some. So some people seem to be "on the ball" with schema.

Answer 41 · 2016-08-22T12:56:45.000Z

Further to @ChiefRA1 discussion above where (it seems to me) that additionalProperty was the best way to describe things like Bedrooms, Baths and Nearby schools.

Beds are now partially covered by numberOfRooms.

Real estate sites tend to refer to facilities within eg a gated community or in the nearby community as Amenities eg the following copied from Zillow Near Shopping, Near Restaurants, Springfield Park, Firewheel Town Center

amenityFeature is described as "An amenity feature (e.g. a characteristic or service) of the Accommodation"

Can amenityFeature be correctly used for eg : 4 bedrooms, 2 bathrooms, Swimming Pool, Double Garage?

What elements should be used for nearby amenities eg Some Community School, Some City Airport, Some Local Nature trail?

Answer 42 · 2016-08-22T21:30:12.000Z

amenityFeature would seem to fit well for things like swimming pools, double garages, etc. We are never going to be able to enumerate all of the features appearing in various real estate listings.

At one point, we discussed a way to model distances between two locations (e.g. a hotel and an airport or a house and a school). @mfhepp Did that get dropped from hotels?

Answer 43 · 2016-08-23T06:46:36.000Z

Yes, use amenityFeature please [edit: for swimming pools, double garages; room count deserves special treatment / vocabulary / attention].

I believe there may be conversations to finish about different room counting conventions between the hotel/accomodation vs real estate usecases.

http://schema.org/numberOfRooms is currently Accommodation-oriented, and says "The number of rooms (excluding bathrooms and closets) of the acccommodation or lodging business. Typical unit code(s): ROM for room or C62 for no unit. The type of room can be put in the unitText property of the QuantitativeValue."

On that point, is a "closet" different to a "water closet" / WC? I had previously interpreted this text as meaning WC, i.e. the room UK-en would call "toilet", whereas a closet is a mere cupboard (more or less universally considered a non-room unless it is walk-in, e.g. a fancy wardrobe).

Regarding distance you're thinking of #831 (@mfhepp: "Local businesses often indicate the distance to other places"; @rvguha: "These are pretty sophisticated constructs. I would like to hold off on these until we have concrete applications that use these").

Answer 44 · 2016-08-23T16:05:51.000Z

Regarding distance you're thinking of #831 (@mfhepp: "Local businesses often indicate the distance to other places"; @rvguha: "These are pretty sophisticated constructs. I would like to hold off on these until we have concrete applications that use these").

Indeed, there was a proposal for DistanceSpecification, see #832

It was first requested by others to decouple this from the hotels proposal, then Guha had some objections/questions, which I tried to address / counter, and then you closed the issue.

Please feel free to reactivate the pull request.

Answer 45 · 2016-08-23T16:15:18.000Z

In the general direction of this proposal:

I am confident you can cover a majority of real-estate use-cases with the current schema.org vocabulary by combining

a) the very granular pricing / terms & conditions properties from schema:Offer and schema:PriceSpecification (and its subtypes)
b) an MTE of schema:Product and a suitable generic schema.org type, like http://schema.org/House
c) a more specific type with schema:additionalType and a type from www.productontology.org (note: The detail pages of that service are currently broken due to a change in the Wikipedia API, but will be fixed asap).
d) schema:amenityFeature for additional property features, and maybe schema:additionalProperty for others

Keep in mind that http://schema.org/LocationFeatureSpecification, as a subtype of http://schema.org/PropertyValue, provided very good means of mapping lightweight textual property / feature information with unique identifiers in an external standard, like RESO or others.

See the examples section on the bottom of http://schema.org/PropertyValue.

It is actually all there, and there is no need to squeeze a domain-specific, granular standard like RESO directly into schema.org. Instead, use the above mentioned elements and add meta-data that maps these to the existing standard.

Thus, the existing standard can evolve independently, we decouple the two modeling efforts, and are in the end all better off.

Martin

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 23 Aug 2016, at 08:46, Dan Brickley notifications@github.com wrote:

Yes, use amenityFeature please.

I believe there may be conversations to finish about different room counting conventions between the hotel/accomodation vs real estate usecases.

http://schema.org/numberOfRooms is currently Accommodation-oriented, and says "The number of rooms (excluding bathrooms and closets) of the acccommodation or lodging business. Typical unit code(s): ROM for room or C62 for no unit. The type of room can be put in the unitText property of the QuantitativeValue."

On that point, is a "closet" different to a "water closet" / WC? I had previously interpreted this text as meaning WC, i.e. the room UK-en would call "toilet", whereas a closet is a mere cupboard (more or less universally considered a non-room unless it is walk-in, e.g. a fancy wardrobe).

Regarding distance you're thinking of #831 (@mfhepp: "Local businesses often indicate the distance to other places"; @rvguha: "These are pretty sophisticated constructs. I would like to hold off on these until we have concrete applications that use these").

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 46 · 2016-08-23T16:50:52.000Z

Thanks @mfhepp. Any thoughts on the numberOfRooms point? can a single property definition serve both accomodation + real estate?

Answer 47 · 2016-08-23T17:23:46.000Z

@danbri: Yes, of course! I think that in my initial proposal, the property was applied to a broader range of objects and @vholland preferred to constrain it to the current set. Feel free to expand the domain of the property to other types or to a new abstract supertype if @rvguha agrees to such a type ;-)

Answer 48 · 2016-08-23T17:48:32.000Z

@mfhepp should it say "only count the toilets if you are selling or long term leasing"?

Answer 49 · 2016-08-23T17:53:51.000Z

@danbri re numberOfRooms: in Germany, toilets in the sense of WCs do not count in a "number of room" spec in real-estate and hotel domains (same as kitchens btw). Closets in the sense of compartments or very small rooms for storage are sometimes counted as half a room (so a 1.5 room flat may mean you have basically one living room, a closet or separate kitchen and a separate WC.

I guess that there is a lot of cultural context in the modeling of such information, so I think we have to live with quite a bit of ambiguity.

Answer 50 · 2016-08-28T09:39:56.000Z

I am much less qualified to discuss this than those above, but I will give my observations related to UK real estate.

Most houses are described as having n Bedrooms, n Bathrooms, n Living rooms. It is assumed the house has 1 kitchen and that a bathroom includes a WC + bath or shower. Where a "bathroom" is just a WC the description may be 1.5 bathrooms or 1 bathroom, 1 WC.

Closets / storage rooms / walk in wardrobes are not normally numbered in the 'headline' info but described in the description.

Apart from the WC and Closet descriptions the same rooms above are questions on insurance applications.

Apart from the WC ambiguity I would think that Bed, Bath and Living - rooms could be used universally in most countries for private homes and hotels.

In most cases when the average person visits a hotel they have 1 bedroom and 1 bathroom. Only in very budget hotels is there no adjoining bathroom and only in more expensive suites is there a living room or more than 1 bedroom or bathroom, with the rare appearance of a kitchen.

So, from my perspective the definitions should focus on 'houses' and allow hotels to share those definitions.

Answer 51 · 2016-08-31T17:09:53.000Z

Martin,

Do you have a proposal for such a type.

Given the significance of real estate markup, we should do whatever we can
to make sure we can express the data found in MLS listings.

Maybe a candidate for the next release (or the one after that)?

guha

On Tue, Aug 23, 2016 at 10:23 AM, Martin Hepp notifications@github.com
wrote:

@danbri https://github.com/danbri: Yes, of course! I think that in my
initial proposal, the property was applied to a broader range of objects
and @vholland https://github.com/vholland preferred to constrain it to
the current set. Feel free to expand the domain of the property to other
types or to a new abstract supertype if @rvguha
https://github.com/rvguha agrees to such a type ;-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlChESoemehKlMGgma7fBoOPBKxIcYks5qiyypgaJpZM4DVNjU
.

Answer 52 · 2016-09-01T15:55:04.000Z

I've been playing with some examples using the schema available in 3.1. I somewhat abused the unitText property to describe the number of bedrooms and bathrooms using QuantitativeValues, but otherwise the schema seemed to work as is.

House for sale:

{
  "@context": "http://schema.org/",
  "@type": ["House", "Product"],
  "@id": "http://www.example.com/house1",
  "description": "Great starter home or investment property.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Any Town",
    "addressRegion": "California",
    "postalCode": "94035"
  },
  "numberOfRooms": 7,
  "numberOfRooms": {
    "@type": "QuantitativeValue",
    "value": 4,
    "unitText": "bedroom"
  },
  "numberOfRooms": {
    "@type": "QuantitativeValue",
    "value": 2,
    "unitText": "bathroom"
  },
  "floorSize": {
    "@type": "QuantitativeValue",
    "value": 1683,  // 1,683 square feet
    "unitCode": "FTK"
  },
  "offers": {
  "@type": "Offer",
  "businessFunction": "http://purl.org/goodrelations/v1#Sell",
  "price": 124900,
  "priceCurrency": "USD",
  "validFrom": "2016-09-01"
  }
}

Home for rent for $4,000 US per month:

{
  "@context": "http://schema.org/",
  "@type": ["Apartment", "Product"],
  "@id": "http://www.example.com/apartment1",
  "description": "Just minutes to all the major High Tech Companies.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street #1",
    "addressLocality": "Mountain View",
    "addressRegion": "CA",
    "postalCode": "94043"
  },
  "numberOfRooms": 7,
  "numberOfRooms": {
    "@type": "QuantitativeValue",
    "value": 3,
    "unitText": "bedroom"
  },
  "numberOfRooms": {
    "@type": "QuantitativeValue",
    "value": 2,
    "unitText": "bathroom"
  },
  "floorSize": {
    "@type": "QuantitativeValue",
    "value": 1400,  // 1,683 square feet
    "unitCode": "FTK"
  },
  "offers": {
  "@type": "Offer",
  "businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
  "priceSpecification": {
    "@type": "UnitPriceSpecification",
    "unitCode": "MON",
    "price": 4000,
    "priceCurrency": "USD"
  },
  "validFrom": "2016-01-19"
  }
}

Answer 53 · 2016-09-01T19:27:04.000Z

I like this. I am not sure I would call it 'abuse'.

guha

On Thu, Sep 1, 2016 at 8:55 AM, vholland notifications@github.com wrote:

I've been playing with some examples using the schema available in 3.1. I
somewhat abused the unitText property to describe the number of bedrooms
and bathrooms using QuantitativeValues, but otherwise the schema seemed to
work as is.

House for sale:

{
"@context": "http://schema.org/",
"@type": ["House", "Product"],
"@id": "http://www.example.com/house1",
"description": "Great starter home or investment property.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Any Town",
"addressRegion": "California",
"postalCode": "94035"
},
"numberOfRooms": 7,
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 4,
"unitText": "bedroom"
},
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
},
"floorSize": {
"@type": "QuantitativeValue",
"value": 1683, // 1,683 square feet
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#Sell",
"price": 124900,
"priceCurrency": "USD",
"validFrom": "2016-09-01"
}
}

Home for rent for $4,000 US per month:

{
"@context": "http://schema.org/",
"@type": ["Apartment", "Product"],
"@id": "http://www.example.com/apartment1",
"description": "Just minutes to all the major High Tech Companies.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street #1",
"addressLocality": "Mountain View",
"addressRegion": "CA",
"postalCode": "94043"
},
"numberOfRooms": 7,
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 3,
"unitText": "bedroom"
},
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
},
"floorSize": {
"@type": "QuantitativeValue",
"value": 1400, // 1,683 square feet
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"unitCode": "MON",
"price": 4000,
"priceCurrency": "USD"
},
"validFrom": "2016-01-19"
}
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCiWrFrxRhRBCalOtmt3JC-s_P_h1ks5qlvVhgaJpZM4DVNjU
.

Answer 54 · 2016-09-01T20:24:28.000Z

Looks good to me, too!

martin hepp
http://www.heppnetz.de

On 01 Sep 2016, at 21:27, R.V.Guha notifications@github.com wrote:

I like this. I am not sure I would call it 'abuse'.

guha

On Thu, Sep 1, 2016 at 8:55 AM, vholland notifications@github.com wrote:

I've been playing with some examples using the schema available in 3.1. I
somewhat abused the unitText property to describe the number of bedrooms
and bathrooms using QuantitativeValues, but otherwise the schema seemed to
work as is.

House for sale:

{
"@context": "http://schema.org/",
"@type": ["House", "Product"],
"@id": "http://www.example.com/house1",
"description": "Great starter home or investment property.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Any Town",
"addressRegion": "California",
"postalCode": "94035"
},
"numberOfRooms": 7,
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 4,
"unitText": "bedroom"
},
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
},
"floorSize": {
"@type": "QuantitativeValue",
"value": 1683, // 1,683 square feet
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#Sell",
"price": 124900,
"priceCurrency": "USD",
"validFrom": "2016-09-01"
}
}

Home for rent for $4,000 US per month:

{
"@context": "http://schema.org/",
"@type": ["Apartment", "Product"],
"@id": "http://www.example.com/apartment1",
"description": "Just minutes to all the major High Tech Companies.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street #1",
"addressLocality": "Mountain View",
"addressRegion": "CA",
"postalCode": "94043"
},
"numberOfRooms": 7,
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 3,
"unitText": "bedroom"
},
"numberOfRooms": {
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
},
"floorSize": {
"@type": "QuantitativeValue",
"value": 1400, // 1,683 square feet
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"unitCode": "MON",
"price": 4000,
"priceCurrency": "USD"
},
"validFrom": "2016-01-19"
}
}

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCiWrFrxRhRBCalOtmt3JC-s_P_h1ks5qlvVhgaJpZM4DVNjU
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 55 · 2016-09-01T21:15:35.000Z

Call me stupid but doesn't the fact the examples use numberOfRooms multiple times go against JSON-LD syntax rules, shouldn't those be arrays instead?

eg,

House for sale:

{
  "@context": "http://schema.org/",
  "@type": ["House", "Product"],
  "@id": "http://www.example.com/house1",
  "name":"House for sale",
  "description": "Great starter home or investment property.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street",
    "addressLocality": "Any Town",
    "addressRegion": "California",
    "postalCode": "94035"
  },
  "numberOfRooms": [
    {
      "@type": "QuantitativeValue",
      "value": 7,
      "unitText":"total number of rooms"
    },
    {
      "@type": "QuantitativeValue",
      "value": 4,
      "unitText": "bedroom"
    },{
      "@type": "QuantitativeValue",
      "value": 2,
      "unitText": "bathroom"
    }
  ],
  "floorSize": {
    "@type": "QuantitativeValue",
    "value": 1683,
    "unitCode": "FTK"
  },
  "offers": {
    "@type": "Offer",
    "businessFunction": "http://purl.org/goodrelations/v1#Sell",
    "price": 124900,
    "priceCurrency": "USD",
    "validFrom": "2016-09-01"
  }
}

Home for rent for $4,000 US per month:

{
  "@context": "http://schema.org/",
  "@type": ["Apartment", "Product"],
  "@id": "http://www.example.com/apartment1",
  "name":"Home for rent",
  "description": "Just minutes to all the major High Tech Companies.",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "123 Main Street #1",
    "addressLocality": "Mountain View",
    "addressRegion": "CA",
    "postalCode": "94043"
  },
  "numberOfRooms": [
    {
      "@type": "QuantitativeValue",
      "value": 7,
      "unitText":"total number of rooms"
    },
    {
      "@type": "QuantitativeValue",
      "value": 3,
      "unitText": "bedroom"
    },{
      "@type": "QuantitativeValue",
      "value": 2,
      "unitText": "bathroom"
    }
  ],
  "floorSize": {
    "@type": "QuantitativeValue",
    "value": 1400,
    "unitCode": "FTK"
  },
  "offers": {
    "@type": "Offer",
    "businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
    "priceSpecification": {
      "@type": "UnitPriceSpecification",
      "unitCode": "MON",
      "price": 4000,
      "priceCurrency": "USD"
    },
    "validFrom": "2016-01-19"
  }
}

The current examples don't parse correctly in Google's Structured Data Testing Tool, Yandex's Structured Data Validator nor JSON-LD Playground yet the array versions do.

Answer 56 · 2016-09-02T06:56:32.000Z

You are right, thanks for spotting this!

But I really like the general direction of reusing the existing generic patterns from GoodRelations in schema.org. Note that additionalProperty and additionalType can also be used for additional information that does not fit otherwise.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 01 Sep 2016, at 23:15, jvandriel notifications@github.com wrote:

Call me stupid but doesn't the fact the examples use numberOfRooms multiple times go against JSON-LD syntax rules, should that be an array instead?

eg,

House for sale:

{
"@context": "http://schema.org/",
"@type": ["House", "Product"],
"@id": "http://www.example.com/house1",
"name":"House for sale",
"description": "Great starter home or investment property.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street",
"addressLocality": "Any Town",
"addressRegion": "California",
"postalCode": "94035"
},
"numberOfRooms": [
{
"@type": "QuantitativeValue",
"value": 7
},
{
"@type": "QuantitativeValue",
"value": 4,
"unitText": "bedroom"
},{
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
}
],
"floorSize": {
"@type": "QuantitativeValue",
"value": 1683,
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#Sell",
"price": 124900,
"priceCurrency": "USD",
"validFrom": "2016-09-01"
}
}

Home for rent for $4,000 US per month:

{
"@context": "http://schema.org/",
"@type": ["Apartment", "Product"],
"@id": "http://www.example.com/apartment1",
"name":"Home for rent",
"description": "Just minutes to all the major High Tech Companies.",
"address": {
"@type": "PostalAddress",
"streetAddress": "123 Main Street #1",
"addressLocality": "Mountain View",
"addressRegion": "CA",
"postalCode": "94043"
},
"numberOfRooms": [
{
"@type": "QuantitativeValue",
"value": 7
},
{
"@type": "QuantitativeValue",
"value": 3,
"unitText": "bedroom"
},{
"@type": "QuantitativeValue",
"value": 2,
"unitText": "bathroom"
}
],
"floorSize": {
"@type": "QuantitativeValue",
"value": 1400,
"unitCode": "FTK"
},
"offers": {
"@type": "Offer",
"businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
"priceSpecification": {
"@type": "UnitPriceSpecification",
"unitCode": "MON",
"price": 4000,
"priceCurrency": "USD"
},
"validFrom": "2016-01-19"
}
}

The current examples don't parse correctly Google's Structured Data Testing Tool, Yandex's Structured Data Validator nor JSON-LD Playground

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 57 · 2016-09-02T07:53:38.000Z

@mfhepp is additionalProperty comparable to additionalType? additionalType is for rdf:type but additionalProperty seems to be used for 'physical' descriptions.

An aside: Google SDTT now processes additionalType.

/jay gray

Answer 58 · 2016-09-02T08:10:12.000Z

@jaygray0919 additionalType takes a type, additionalProperty takes a http://schema.org/PropertyValue with many possible patterns, scroll down that page for plenty of examples.

What do you mean by "An aside: Google SDTT now processes additionalType."? That it recognizes the property or that it processes e.g. www.productontology.org types?

Answer 59 · 2016-09-02T08:31:54.000Z

@mfhepp Copy that.

WRT additionalType, GSDTT (until recently - perhaps updated for 3.0) did not process additionalType. For example, this JSON-LD example threw an error on GSDTT:
https://schema.org/additionalType
However, GSDTT did properly process the Microdata example.

WRT schema:meta and "additional properties", one cannot easily distinguish between an owl:AnnotationProperty and an owl:ObjectProperty. When I first read your comment above about additionalProperty I thought there was a new Schema feature that handled the owl distinction. No need to comment on this further.

/jay gray

Answer 60 · 2016-09-03T13:34:29.000Z

Thanks to @vholland and @jvandriel for the examples for dealing with a House.

Note Google Validator states "The property offers is not recognized by Google for an object of type House."

Comments / Questions
I am assuming the values total number of rooms (7), includes bedrooms (4), Bathrooms (2) and implies that there is an unnamed room - probably a Living Room / Lounge.

I am assuming that it could be included as follows (please comment)?
"@type": "QuantitativeValue",
"value": 1,
"unitText": "living room"

Unfortunately (I am assuming) the 'total number of rooms' requires some form of calculation (manually or Programmatically) and probably an extra field in a DB to hold this total value. Maybe this is seen as trivial.

Whereas if there were individual values for Bedrooms, Living Rooms, Bathrooms then these could be entered directly into a DB and read directly with no need for a Total calculation.

If bathrooms are included in the totals in the examples above is it appropriate to include Bathrooms, as schema.org state "The number of rooms (excluding bathrooms and closets) " for value numberOfRooms? If not how would # bathrooms be identified?

As previously, I bow to the expertise of others in this thread, so feel free to tell me where I am wrong.

Answer 61 · 2016-09-09T22:10:55.000Z

The numberOfRooms is not standardized across the MLS associations. Each has their own rules for what qualifies as a room. Nor does NAR whose RESO standard definition for RoomsTotal is ambiguous. All of this makes me equally curious why schema.org chose to exclude bathrooms and closets from the definition.

Answer 62 · 2016-09-12T03:28:49.000Z

What do you suggest we do?

guha

On Fri, Sep 9, 2016 at 3:11 PM, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each
has their own rules for what qualifies as a room. Nor does NAR whose RESO
standard definition for RoomsTotal is ambiguous. All of this makes me
equally curious why schema.org chose to exclude bathrooms and closets
from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCgDbUFkbwkUkvs6n1QgRCeOb8qYyks5qodl2gaJpZM4DVNjU
.

Answer 63 · 2016-09-12T10:14:14.000Z

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms" is pretty useless if you do not know whether it is a 4-bedroom apartment or a small condomium with two closets and a bathroom. If we force publishers or data to map to this more precise definition, that is a good thing.
You can always add meta-data about your data using either the unitText property or the valueReference property.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each has their own rules for what qualifies as a room. Nor does NAR whose RESO standard definition for RoomsTotal is ambiguous. All of this makes me equally curious why schema.org chose to exclude bathrooms and closets from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 64 · 2016-09-12T14:16:49.000Z

Total rooms is a pretty standard field for most tax systems and closets are not usually counted, but localalities may have their own rules. Also note real estate data in the U.S. and Canada is pretty flat. Properly normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

On Mon, Sep 12, 2016 at 3:14 AM -0700, "Martin Hepp" <notifications@github.com mailto:notifications@github.com> wrote:

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms" is pretty useless if you do not know whether it is a 4-bedroom apartment or a small condomium with two closets and a bathroom. If we force publishers or data to map to this more precise definition, that is a good thing.
You can always add meta-data about your data using either the unitText property or the valueReference property.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each has their own rules for what qualifies as a room. Nor does NAR whose RESO standard definition for RoomsTotal is ambiguous. All of this makes me equally curious why schema.org chose to exclude bathrooms and closets from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/241#issuecomment-246305672, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQn_gPCpKWfuGFtffygtDpbpvjE47RiQks5qpSYCgaJpZM4DVNjU.

Answer 65 · 2016-09-12T15:36:41.000Z

You have to keep in mind that the typical consumers of schema.org markup are not typical transaction-processing systems in the 1990s style, but search engines that can take a lot of contextual information and other signals into consideration when presenting information or making decisions on the basis.

For instance, I am pretty sure that Google et al. is able to take into account the geo-location of the server IP address, the geo-location of the business, or the geo-location and language preferences of the Web user using Google when using the value of a "numberOfRooms" property.

So what are you exactly proposing - shall we use a less useful and more ambiguous definition, dropping the exclusion of bathrooms and closets?

On 12 Sep 2016, at 16:16, RobLarsonCRMLS notifications@github.com wrote:

Total rooms is a pretty standard field for most tax systems and closets are not usually counted, but localalities may have their own rules. Also note real estate data in the U.S. and Canada is pretty flat. Properly normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

Answer 66 · 2016-09-12T15:50:33.000Z

Understanding the nuances from living the issues for a lot of years. When you go back and forth from flat to normalized data, if handling is done correct data ends up being lost. Also geolocation probably isn’t the best tool for local rules but rather county ownership. We have county lines where properties cross the line, but are still part of the county that they are outside of. One of the reasons we bring country data in for insertion and/or reference to the property data.

An example might be that say you have a relational structure so the parties to a transaction are not flat in the property data. You need to make sure your transactional history of roster is very well related to that roster record at the time of the property record being active. We have regular subpoena’s that require the data to be “as it was” at the time of activity. If done correctly it isn’t an issue and the record as it was can easily be reproduced, but too often this isn’t done and the data is misrepresented. Then when you factor in how the data is replicated to thousands of client systems, anything but a simple flat representation is unmanageable and misrepresentation becomes common place. However, if the source manages this, then the data would flow in a flat simple fashion to the client. At that point, what is the schema about, your back end, or how systems communication. RESO is about the pipe, the movement of the data, and as a result is very flat. Most of our back ends are quite normalized.

Aside from parties to a transaction there are also changes to properties that need to be retained, so even a property to listing relationship can end up altering the past if the transactional history when a past listing is brought to view isn’t property handled. Beds, Baths, Sqft all change with enough frequency to be a consideration.

The business (and it’s imperfections of data flow) wag the technology.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.orgmailto:rob@crmls.org

Answer 67 · 2016-09-12T16:01:24.000Z

Being a complete newbie to designing data structures for information systems, I am glad to learn that anything but a simple flat representation is unmanageable. Before this enlightement, I had been deeply confused by such disturbing and heretical works like [1] and [2].

What I have not understood though is what you propose as for http://schema.org/numberOfRooms so that business (and it’s imperfections of data flow) can actually wag the technology.

[1] http://web.mit.edu/smadnick/www/wp/2003-04.pdf
[2] https://www.amazon.com/Data-Reality-Perspective-Perceiving-Information/dp/1935504215

On 12 Sep 2016, at 17:50, RobLarsonCRMLS notifications@github.com wrote:

Understanding the nuances from living the issues for a lot of years. When you go back and forth from flat to normalized data, if handling is done correct data ends up being lost. Also geolocation probably isn’t the best tool for local rules but rather county ownership. We have county lines where properties cross the line, but are still part of the county that they are outside of. One of the reasons we bring country data in for insertion and/or reference to the property data.

An example might be that say you have a relational structure so the parties to a transaction are not flat in the property data. You need to make sure your transactional history of roster is very well related to that roster record at the time of the property record being active. We have regular subpoena’s that require the data to be “as it was” at the time of activity. If done correctly it isn’t an issue and the record as it was can easily be reproduced, but too often this isn’t done and the data is misrepresented. Then when you factor in how the data is replicated to thousands of client systems, anything but a simple flat representation is unmanageable and misrepresentation becomes common place. However, if the source manages this, then the data would flow in a flat simple fashion to the client. At that point, what is the schema about, your back end, or how systems communication. RESO is about the pipe, the movement of the data, and as a result is very flat. Most of our back ends are quite normalized.

Aside from parties to a transaction there are also changes to properties that need to be retained, so even a property to listing relationship can end up altering the past if the transactional history when a past listing is brought to view isn’t property handled. Beds, Baths, Sqft all change with enough frequency to be a consideration.

The business (and it’s imperfections of data flow) wag the technology.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.orgmailto:rob@crmls.org

Answer 68 · 2016-09-12T16:20:37.000Z

I was speaking more globally and not specifically about your number of rooms, other than my comment about the definition of that field may vary from locality to locality. Bedrooms also have conditions such as the inclusion of a closet, but that’s not a hard rule everywhere you go either. Cities is another fun one. Even the USPS support non-cities in their list. When it comes to property sales it gets more exciting with all the local control and decisions. Some systems hold a Postal City and a City. That way they have the consistency of a list of incorporated cities only, but everyone (postal, print, USPS, etc.) don’t exclusively use the incorporated list.

But flat data is typically bad design. Not arguing that. Just sharing the reasons we’re so flat in organized real estate.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.orgmailto:rob@crmls.org

Answer 69 · 2016-09-12T16:34:53.000Z

[I don't find that sarcasm works well in this environment.]

As a Google engineer, I am limited in my ability to speculate in public on how our systems work. What I can say is that we value clear definitions, and find merit in structured data records that do not need a huge amount of context-related heuristics to make them usable. While Google is very good at making informed guesses about data, that is no reason to avoid writing things down unambiguously whenever possible.

In this case we have several reasonable strands of thought leading to difficult design questions:

It makes a lot of sense to try to maximize vocabulary sharing between the hotels/accommodation and real estate usecases. Even if we note that there are different (for example) room-counting conventions between these domains, exacerbated by geographical and other variations.
We have to be pragmatic about the limited knowledge many sites have about their own data, and their own ability to influence upstream data sources. They may well not know whether bathrooms were counted or not, and pressure from search-oriented markup may not help, if they really can't be sure about the exact semantics of a field.
It is a great pity for the cases where a site does really know what a field is counting, if we neglect to provide them with a precise enough property to capture that reliably. A three bedroom flat and a five bedroom flat are substantially different living environments, as has been pointed out.

Could we explore the use of small sub-property / super-property hierarchies as a tool for navigating these tradeoffs?

For example in the numberOfRooms case, we could make a broad super-property whose documentation mentioned the ambiguities and offered e.g. specialized sub-properties such as:

numberOfRooms "The numberOfRooms. In accommodation settings it is conventional not to count bathrooms/WCs. Many geographical conventions exist. Use a subproperty for more precision."
- numberOfRoomsExcludingWaterOrientedRooms
- numberOfRoomsIncludingWaterOrientedRooms

While these specifics may be the wrong things to count, and I've used slightly ridiculous names on purpose, would such a technical approach give us a bit more machinery for finding consensus?

Answer 70 · 2016-09-12T18:07:56.000Z

MLS listings in the US are highly regulated, and as discussed, definitions may differ state to state or even by municipality. Given that, it may be better to have a basic set of properties for House, etc. and if people are interested, expand on the schema with an MLS-specific extension.

Answer 71 · 2016-09-12T18:08:34.000Z

@danbri I think there is enough support thru this issue that we should create a subproperty for Bedroom Count that a lot of common folks could develop against. By simply adding the term 'Bed' in a proposed one of the properties could clear things up considerably and allow for those that have precision data about the number of bedrooms.

numberOfRooms "The numberOfRooms. In accommodation settings it is conventional not to count bathrooms/WCs. Many geographical conventions exist. Use a subproperty for more precision."
- numberOfRoomsExcludingWaterOrientedRooms
- numberOfRoomsIncludingWaterOrientedRooms
numberofBedrooms "The count of rooms designed for sleeping accommodations. These bedrooms might include a closest in the bedroom, or not.

@RobLarsonCRMLS @mfhepp @vholland agreed... start simple...then expand.

Answer 72 · 2016-09-12T18:15:49.000Z

@RobLarsonCRMLS and to ease your historical pains...we could add your usecase of a 'recordedDate' or somesuch:

recordedDate "The date that this accomodation's property values were captured, created ,updated'

Answer 73 · 2016-09-13T00:52:37.000Z

On Mon, Sep 12, 2016 at 3:14 AM, Martin Hepp notifications@github.com
wrote:

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms"
is pretty useless if you do not know whether it is a 4-bedroom apartment or
a small condomium with two closets and a bathroom. If we force publishers
or data to map to this more precise definition, that is a good thing.

This philosophy can be taken too far.

You can always add meta-data about your data using either the unitText
property or the valueReference property.

That is absolutely the last resort and should not be encouraged.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each
has their own rules for what qualifies as a room. Nor does NAR whose RESO
standard definition for RoomsTotal is ambiguous. All of this makes me
equally curious why schema.org chose to exclude bathrooms and closets
from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCkl9qKUDXsxluWRZ4H2raW7xRPcJks5qpSX9gaJpZM4DVNjU
.

Answer 74 · 2016-09-13T00:54:21.000Z

Rob,

What do you suggest we do? Making it easy to get US and Canadian listings
into schema.org should be the top design priority for this schema.

guha

On Mon, Sep 12, 2016 at 7:16 AM, RobLarsonCRMLS notifications@github.com
wrote:

Total rooms is a pretty standard field for most tax systems and closets
are not usually counted, but localalities may have their own rules. Also
note real estate data in the U.S. and Canada is pretty flat. Properly
normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

On Mon, Sep 12, 2016 at 3:14 AM -0700, "Martin Hepp" <
notifications@github.commailto:notifications@github.com> wrote:

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms"
is pretty useless if you do not know whether it is a 4-bedroom apartment or
a small condomium with two closets and a bathroom. If we force publishers
or data to map to this more precise definition, that is a good thing.

You can always add meta-data about your data using either the unitText
property or the valueReference property.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each
has their own rules for what qualifies as a room. Nor does NAR whose RESO
standard definition for RoomsTotal is ambiguous. All of this makes me
equally curious why schema.org chose to exclude bathrooms and closets
from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/
/issues/241#issuecomment-246305672>, or mute the
thread<https://github.com/notifications/unsubscribe-auth/AQn_
gPCpKWfuGFtffygtDpbpvjE47RiQks5qpSYCgaJpZM4DVNjU>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCvBcEQiLcWZ_PMAd-Uacg3tWViZqks5qpV7XgaJpZM4DVNjU
.

Answer 75 · 2016-09-13T00:58:41.000Z

Martin,

I think one of the problems is that schema.org information is a bit too
hard to consume today. It takes a Microsoft or Google to do it. We would
very much like to make it much easier for a lot of people to build apps
using schema.org

guha

On Mon, Sep 12, 2016 at 8:36 AM, Martin Hepp notifications@github.com
wrote:

You have to keep in mind that the typical consumers of schema.org markup
are not typical transaction-processing systems in the 1990s style, but
search engines that can take a lot of contextual information and other
signals into consideration when presenting information or making decisions
on the basis.

For instance, I am pretty sure that Google et al. is able to take into
account the geo-location of the server IP address, the geo-location of the
business, or the geo-location and language preferences of the Web user
using Google when using the value of a "numberOfRooms" property.

So what are you exactly proposing - shall we use a less useful and more
ambiguous definition, dropping the exclusion of bathrooms and closets?

On 12 Sep 2016, at 16:16, RobLarsonCRMLS notifications@github.com
wrote:

Total rooms is a pretty standard field for most tax systems and closets
are not usually counted, but localalities may have their own rules. Also
note real estate data in the U.S. and Canada is pretty flat. Properly
normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCsioEgi3tITFX21LWDCIo0aK1_r7ks5qpXGQgaJpZM4DVNjU
.

Answer 76 · 2016-09-13T01:51:28.000Z

I managed to dig up a RETS 2.0 document from 2007. We spent a couple years (this might be some draft along the way) and created a solid schema that would serve to encompass any aspect of real estate data. Adoption of the RETS standard dropped and most considered the standard likely dead after 1.72/1.8. RETS 2.0 was very well built, but largely unusable by the majority of the community.

RESO was formed a little later and I’ve attached a document I created around the new direction.

I’m definitely not judging your work for schema.org and I’m hopeful we will have a good bridge between RESO and what your working on. I’m not looking deep enough to have an opinion. Sorry, just too much on my plate. But when I catch a note I’ll try to pitch in any lessons learned on our end or any details about how real estate work (business rules).

One particular area that we are trying to fix, and this will be long term, is what we call “Property Type”. It’s real working name is Property Sub Type, and specifically the sub type to Residential. Therein you will find what you typically see out on public sites. A combination of ownership and structural types. I couldn’t believe it when I first laid eyes 14 years ago. But it’s so engrained across thousands of sites that it’s going to be a long road. We’re working on a separate Land Ownership (call it CID, Subdivision Type, etc.,) and we’re working on structure types (which is where Townhouse really belongs). So you might want to work up accommodations for both methods as I feel it could take years to convert the industry and it’s many tentacles of data. We’re meeting again on this topic this week and maybe we will have some good progress. I’m working to have these two enumerated lists defined and vetted so we can get them ratified in the spring.

All the best.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.orgmailto:rob@crmls.org

From: R.V.Guha [mailto:notifications@github.com]
Sent: Monday, September 12, 2016 5:59 PM
To: schemaorg/schemaorg schemaorg@noreply.github.com
Cc: Rob Larson Rob@crmls.org; Mention mention@noreply.github.com
Subject: Re: [schemaorg/schemaorg] Guidance or vocab needed regarding Real Estate (property purchase, rental etc.) (#241)

Martin,

I think one of the problems is that schema.org information is a bit too
hard to consume today. It takes a Microsoft or Google to do it. We would
very much like to make it much easier for a lot of people to build apps
using schema.org

guha

On Mon, Sep 12, 2016 at 8:36 AM, Martin Hepp notifications@github.com
wrote:

You have to keep in mind that the typical consumers of schema.org markup
are not typical transaction-processing systems in the 1990s style, but
search engines that can take a lot of contextual information and other
signals into consideration when presenting information or making decisions
on the basis.

For instance, I am pretty sure that Google et al. is able to take into
account the geo-location of the server IP address, the geo-location of the
business, or the geo-location and language preferences of the Web user
using Google when using the value of a "numberOfRooms" property.

So what are you exactly proposing - shall we use a less useful and more
ambiguous definition, dropping the exclusion of bathrooms and closets?

On 12 Sep 2016, at 16:16, RobLarsonCRMLS notifications@github.com
wrote:

Total rooms is a pretty standard field for most tax systems and closets
are not usually counted, but localalities may have their own rules. Also
note real estate data in the U.S. and Canada is pretty flat. Properly
normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCsioEgi3tITFX21LWDCIo0aK1_r7ks5qpXGQgaJpZM4DVNjU
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/241#issuecomment-246541963, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQn_gM4q928PseV7fyJycQLFuEu-n56cks5qpfVNgaJpZM4DVNjU.

Answer 77 · 2016-09-13T01:58:23.000Z

If you want easy…

http://ddwiki.reso.org . But she be flat as a pancake. Anyone with technical background will cringe. I hate to say it, but it is what it is…

Some good news, you’ll find these fields with “[Type]” in the field name. It’s my creative way to give the option for both flat (which a lot have) and a relational instance. I have them on the Rooms, Unit Types and the Green Verification Programs. So we have a little dimension (even though it’s optional). ☺ Baby steps.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.orgmailto:rob@crmls.org

From: R.V.Guha [mailto:notifications@github.com]
Sent: Monday, September 12, 2016 5:55 PM
To: schemaorg/schemaorg schemaorg@noreply.github.com
Cc: Rob Larson Rob@crmls.org; Mention mention@noreply.github.com
Subject: Re: [schemaorg/schemaorg] Guidance or vocab needed regarding Real Estate (property purchase, rental etc.) (#241)

Rob,

What do you suggest we do? Making it easy to get US and Canadian listings
into schema.org should be the top design priority for this schema.

guha

On Mon, Sep 12, 2016 at 7:16 AM, RobLarsonCRMLS notifications@github.com
wrote:

Total rooms is a pretty standard field for most tax systems and closets
are not usually counted, but localalities may have their own rules. Also
note real estate data in the U.S. and Canada is pretty flat. Properly
normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

On Mon, Sep 12, 2016 at 3:14 AM -0700, "Martin Hepp" <
notifications@github.commailto:notifications@github.com> wrote:

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms"
is pretty useless if you do not know whether it is a 4-bedroom apartment or
a small condomium with two closets and a bathroom. If we force publishers
or data to map to this more precise definition, that is a good thing.

You can always add meta-data about your data using either the unitText
property or the valueReference property.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each
has their own rules for what qualifies as a room. Nor does NAR whose RESO
standard definition for RoomsTotal is ambiguous. All of this makes me
equally curious why schema.org chose to exclude bathrooms and closets
from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/
/issues/241#issuecomment-246305672>, or mute the
thread<https://github.com/notifications/unsubscribe-auth/AQn_
gPCpKWfuGFtffygtDpbpvjE47RiQks5qpSYCgaJpZM4DVNjU>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCvBcEQiLcWZ_PMAd-Uacg3tWViZqks5qpV7XgaJpZM4DVNjU
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com//issues/241#issuecomment-246541321, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AQn_gOi2GWnTlbkEAcEuny21BLIJbmRcks5qpfRIgaJpZM4DVNjU.

Answer 78 · 2016-09-13T07:35:09.000Z

i suggest using additionalProperty with RESO identifiers for propertyID, see exsmples on schema:PropertyValue. This will be precise and still decouple the evolution of the two vocabs.

martin hepp
www: http://www.heppnetz.de/
email: mhepp@computer.org

Am 13.09.2016 um 02:54 schrieb R.V.Guha notifications@github.com:

Rob,

What do you suggest we do? Making it easy to get US and Canadian listings
into schema.org should be the top design priority for this schema.

guha

On Mon, Sep 12, 2016 at 7:16 AM, RobLarsonCRMLS notifications@github.com
wrote:

Total rooms is a pretty standard field for most tax systems and closets
are not usually counted, but localalities may have their own rules. Also
note real estate data in the U.S. and Canada is pretty flat. Properly
normalized data can become a challenge if not governed with this in mind.

Rob Larson
Chief Information Officer
California Regional MLS

T 909.859.2055 | C 909.263.1263 | E rob@crmls.org

On Mon, Sep 12, 2016 at 3:14 AM -0700, "Martin Hepp" <
notifications@github.commailto:notifications@github.com> wrote:

My two cents:

The current design is more precise and thus IMO more useful. "4 rooms"
is pretty useless if you do not know whether it is a 4-bedroom apartment or
a small condomium with two closets and a bathroom. If we force publishers
or data to map to this more precise definition, that is a good thing.

You can always add meta-data about your data using either the unitText
property or the valueReference property.

martin hepp http://www.heppnetz.de
mhepp@computer.org @mfhepp

On 10 Sep 2016, at 00:10, dmills59 notifications@github.com wrote:

The numberOfRooms is not standardized across the MLS associations. Each
has their own rules for what qualifies as a room. Nor does NAR whose RESO
standard definition for RoomsTotal is ambiguous. All of this makes me
equally curious why schema.org chose to exclude bathrooms and closets
from the definition.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://github.com/
/issues/241#issuecomment-246305672>, or mute the
thread<https://github.com/notifications/unsubscribe-auth/AQn_
gPCpKWfuGFtffygtDpbpvjE47RiQks5qpSYCgaJpZM4DVNjU>.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFAlCvBcEQiLcWZ_PMAd-Uacg3tWViZqks5qpV7XgaJpZM4DVNjU
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

Answer 79 · 2016-09-13T10:30:23.000Z

@vholland @thadguidry As for the numberOfRooms definition: It would also be possible to

a) create a subtype of QuantitativeValue like schema:RoomSpecification with two new boolean property includesBathrooms and includesClosets, but I am not so much in favor of this route, because it pollutes the very generic and powerful QuantitativeValue pattern in schema.org

b) define a canonical http://schema.org/unitCode value for each variant, either as a URI or a prefixed string, like
reso:RIBC (rooms including bathrooms and closets),
reso:RIB (rooms including bathrooms)
reso:RIC (rooms including closets)

We could then relax the textual definition of number of rooms ("typically excluding bathrooms and closets. unitCode may indicate the exact definition").

Then publishers of data CAN be unambiguous but other with less pristine data sources can still populate the property. And we do not need to change anything.

As a general guideline, I would love to see more canonical identifiers for elements from external vocabularies that can be used in combination with

http://schema.org/unitCode for units
http://schema.org/QualitativeValue for enumerated values of any kind
http://schema.org/propertyID for properties defined in external standards and
URIs of more specific types from external standards, in the same way as provided by www.productontology.org, to be used for multi-typed entities or in combination with http://schema.org/additionalType.

By this, external standards can be a valuable complement to schema.org without needing to integrate and align the entire vocabulary, which is often very a lot of work and difficult for

legal (copyrights),
conceptual (mismatches in the underlying models),
terminological (e.g. naming conventions in schema.org or clashes with existing elements), and
4.managerial (evolution and change)

reasons.

Answer 80 · 2016-09-13T16:14:08.000Z

Before we start creating booleans or new unitCodes, I would like to take a step back to determine the use cases and how likely sites are to use any of the proposed schema.

Answer 81 · 2016-09-13T16:51:44.000Z

It might also be possible for such a "generic and powerful" long form to be used by us at schema.org to document the semantics of a "cheap and cheerful" dedicated property. There may be some middle ground design space in which a common conceptual model ties things together behind the scenes, but we define simple dedicated properties with explicit hardcoded meaning to keep the markup simple for publishers.

Answer 82 · 2016-09-13T18:38:12.000Z

@mfhepp your amazing. In so many ways :) :) but I get what your trying to teach us here, but publishers needs must come first.

@danbri Righto. and that middle ground would still make @rvguha and me happy. We continue to fulfill our original mission plan = When we must, we agree to make developers lives easier and make consumers lives a bit harder.

Answer 83 · 2016-09-13T20:54:38.000Z

@vholland while there may be significant investment sunk in the current site “data models” they serve a fleet of technology that is anything but standardized and not concerned about contextualizing data so that search engines can make reasonable decisions about the data. This represents a huge loss of value in the data by the agencies and associations who generate it and, in an internet-oriented economy, completely counter-productive in the buyer-seller relationship. So the use cases we’re really interested involve having the industries (like real estate or hotels) evolve with these very internet-friendly technologies.

To the specific issue of numberOfRooms the suggestion by @mfhepp is a particularly useful one:

b) define a canonical http://schema.org/unitCode value for each variant, either as a URI or a prefixed string, like
reso:RIBC (rooms including bathrooms and closets),
reso:RIB (rooms including bathrooms)
reso:RIC (rooms including closets)

Useful and important because it creates a way to bring the industry-specific knowledge into the equation immediately without enduring more grueling mapping efforts. Do this now and create an on-ramp for developers and start creating structured property data.

http://schema.org/propertyID for properties defined in external standards and

URIs of more specific types from external standards, in the same way as provided bywww.productontology.org, to be used for multi-typed entities or in combination withhttp://schema.org/additionalType.

Answer 84 · 2016-11-05T23:22:42.000Z

Sorry I've lagged on getting this started. Here's my first pass

Motivation & Approach

It's certainly possible to bring more from RESO into schema.org, I've limited my suggested adds and examples to what I think is necessary to support the following:

A better search experience for consumers, e.g. searching "houses for sale in funky town" should return a list of houses for sale, not a list of pages created to capture the keyword and geography.
Rich cards for real estate listings including
1. bedrooms
2. bathrooms
3. price
4. images
SERP listings compliant with industry rules for display of the listing agent/broker info.

Summary of Proposed Schema.org Extensions

New properties on Accommodation
- numberOfBedrooms
- numberOfBathrooms
New Accommodation subtypes
- TimeShare
- StockCooperative
- Townhouse
- Triplex
- House
  - Cabin
  - Condominium
  - Duplex
  - ManufacturedHome
  - MobileHome
  - Quadruplex
  - StockCooperative
  - Townhouse
  - Triplex

Core Classes

Real Estate Agent

RealEstateAgent a business who acts as an intermediary between sellers and buyers of real estate/real property and attempts to find sellers who wish to sell and buyers who wish to buy.

{
 "@context"  : "http://schema.org",
 "@type"     : "RealEstateAgent",
 "name"      : "Josh Flagg",
 "url"       : "https://joshflagg.com",
 "telephone" : "310-623-8703",
 "email"     : "josh@joshflagg.com"
}

Team, Office or Franchise Affiliation

If an agent is part of a larger organization, such as a team, office or brokerage, use schema:memberOf which expects a value of type schema:Organization.

{
  "memberOf" : [
    {
      "@type": "RealEstateAgent",
      "name" : "Rodeo Realty",
      "url"  : "http://www.rodeore.com"
    }
  ]
}

openingHours - The general opening hours for a business. Opening hours can be specified as a weekly time range, starting with days, then times per day. Multiple days can be listed with commas ',' separating each day. Day or time ranges are specified using a hyphen '-'.

{
  "openingHours" : "Mo,Tu,We,Th,Fr 09:00-16:00"
}

image - photos or videos of a subject. Values can be objects (schema:ImageObject, schema:VideoObject) or a URL reference to an image or video.

{
  "image" : [ "https://joshflagg.com/images/josh.jpg" ]
}

sameAs - URL reference to a web page that unambiguously indicates the subject's identity.

{
  "sameAs"       : [
    "https://www.facebook.com/joshflagg", 
    "https://twitter.com/joshflagg1"
  ]
}

Accommodations (Real Property)

Accommodation is the schema.org top level class for a unit of residential real property, and is roughly equivalent to RESO data-dictionary Property.

Types of Accommodations

New accommodation types are proposed for real estate offers.

Apartment
House
- SingleFamilyResidence
- Cabin (proposed)
- Condominium (proposed)
- Duplex (proposed)
- ManufacturedHome (proposed)
- MobileHome (proposed)
- Quadruplex (proposed)
- StockCooperative (proposed)
- Townhouse (proposed)
- Triplex (proposed)
Farm (proposed)
Land (proposed)
BoatSlip (proposed)
TimeShare (proposed)

Location, Location, Location

The physical location of an accommodation can be declared by address (PostalAddress) or geo (GeoCoordinates).

Core Accommodation Attributes for Real Estate Offers

These properties have particular importance in the context of real estate search (query) and result lists for real estate Offers.

numberOfBedrooms (Proposed) - the number of bedrooms in an accommodation.
numberOfBathrooms (Proposed) - The simple sum of the number of bathrooms in an accommodation. For example a single family residence with two full bathrooms and one half bathroom, the numberOfBathrooms value should be 3.
floorSize - the size of an accommodation, typically expressed in square meters (MTK), square foot (FTK) or square yard (YDK)

Example: a single family house with 4 bedrooms and 3 bathrooms.

{
 "@context": "http://schema.org",
 "@type": "SingleFamilyResidence",
 "numberOfBedrooms": "4",
 "numberOfBathrooms": "3",
 "floorSize": {
   "@type": "QuantitativeValue",
   "value": "3300",
   "unitCode": "FTK",
  },
  "address": {
     "@type": "PostalAddress",
     "streetAddress": "55 Gypsy Lane",
     "addressLocality": "Berkeley",
     "addressRegion": "CA",
     "postalCode": "94705"
 }
}

Real Estate Offers (Listings)

A reso:PropertyListing is represented in schema.org as an Offer. businessFunction (e.g. sell, lease) of the offer, the common values being:

http://purl.org/goodrelations/v1#Sell (default)
http://purl.org/goodrelations/v1#LeaseOut

Use price to express reso:ListPrice, numeric values are preferred. Use ISO 4217 codes to indicate priceCurrency. For price ranges, use the alternate PriceSpecification format.

Basic Pattern for Real Estate Offers

{
 "@context"           : "http://schema.org/",
 "@type"              : "Offer",
 "businessFunction"   : "http://purl.org/goodrelations/v1#Sell",
 "price"              : "1500000",
 "priceCurrency"      : "USD",
 "name"               : "55 Gypsy Lane, Berkeley, CA 94705",
 "description"        : "Inspired by the glorious chateaus of France, Chateau Ami is a sophisticated and luxurious retreat that reflects that magical merging of inspiration and architecture."
 "url"                : "http://example.com/listings/1234"
}

Use itemOffered to associate the Offer and accommodation.

"itemOffered": {
 "@type"             : "SingleFamilyResidence",
 "numberOfBedrooms"  : "4",
 "numberOfBathrooms" : "3",
 "floorSize": {
   "@type"    : "QuantitativeValue",
   "value"    : "3300",
   "unitCode" : "FTK",
  },
  "address": {
     "@type"           : "PostalAddress",
     "streetAddress"   : "55 Gypsy Lane",
     "addressLocality" : "Berkeley",
     "addressRegion"   : "CA",
     "postalCode"      : "94705"
 }
}

use offeredBy to associate the listing agent and broker to the offer.

"offeredBy": [
  {
   "@context"  : "http://schema.org",
   "@type"     : "RealEstateAgent",
   "name"      : "Josh Flagg",
   "url"       : "https://joshflagg.com",
   "telephone" : "310-623-8703",
   "email"     : "josh@joshflagg.com"
  },
  {
      "@type": "RealEstateAgent",
      "name" : "Rodeo Realty",
      "url"  : "http://www.rodeore.com"
   }
]

Open House Event (proposed)

an event hosted by a real estate agent to show a listed property to the general public. Use offers to associate the listing property being held open.

{
  "@context"    : "http://schema.org",
  "@type"       : "Event",
  "startDate"   : "2016-11-06T14:00:00-07:00", 
  "endDate"     : "2016-11-06T16:30:00-07:00",
  "name"        : "Open House 10am - 2pm",
  "description" : "Inspired by the glorious chateaus...",
  "url"         : "http://example.com/listings/123-main-street", 
  "image"       : [ 
    "http://example.com/media/123-main-street/0", 
    "http://example.com/media/123-main-street/1" 
  ],
  "offers"    : {
   "@type"              : "Offer",
   "businessFunction"   : "http://purl.org/goodrelations/v1#Sell",
   "price"              : "1500000",
   "priceCurrency"      : "USD",
   "url"                : "http://example.com/listings/1234"
  },
  "location": {
    "@type"             : "SingleFamilyResidence",
    "name"              : "55 Gypsy Lane",
    "address" : {
     "@type"           : "PostalAddress",
     "streetAddress"   : "55 Gypsy Lane",
     "addressLocality" : "Berkeley",
     "addressRegion"   : "CA",
     "postalCode"      : "94705"
    }
  },
  "performer": {
     "@type"     : "RealEstateAgent",
     "name"      : "Josh Flagg"
   }
}

Answer 85 · 2016-11-06T13:36:47.000Z

I'm feeling a little embarrassed. I was so excited about completing a long standing todo off my list that I failed to notice how the conversation has evolved while I was away. I'm sorry about that. The good news is I seem to have reached nearly identical results and if we can resolve a few minor differences we could get some guidance out for publishers quickly.

Answer 86 · 2016-11-06T14:14:50.000Z

RealEstateAgent needs a property for state/regional license information.

In many regions agents are required to display their license info on anything designed to promote first contact with a consumer. Map list results on a search for real estate agents would certainly fit this description so I'm surprised this didn't come up sooner.

RESO has this in two fields for the license number and issuing state but it's typically displayed as string like "CA DRE#1235".

I'm sure this sort of requirement is not unique to real estate so perhaps I'm missing an existing property of Org or LocalBusiness - if so please let me know.

Answer 87 · 2016-11-07T08:41:35.000Z

@dduran1967 - great overview of proposals.

A couple of specific comments:

Team, Office or Franchise Affiliation

This, as with Organizations elsewhere in Schema.org, should be handled using Oraganization> parentOrganization and Organization > subOrganization. eg:


  "parentOrganization" : 
    {
      "@type": "RealEstateAgent",
      "name" : "Rodeo Realty",
      "url"  : "http://www.rodeore.com"
    }

memberOf would be used to describe where an organisation is a member of an external organisation such as a trade association:
Asian Real Estate Association of America (AREAA)

  "memberOf": "Asian Real Estate Association of America (AREAA) "

Types of Accommodations

Is there an authoritative list of these available elsewhere? Managing long sets of enumeration values is not an ideal use case for Schema.org. These inevitably change and added to over time, and the proposal process, backed by a group of engaged sector knowledgeable folks, tends to loose focus after initial adoption.

Even adding to them to Wikidata would be more flexible, and allow such types to be maintained over time. That would help also with geographic differences - as a Brit I have no idea what a Quadruplex, StockCooperative, or Triplex represents, and would be looking for the proposal for a Bungalow type.

Answer 88 · 2016-11-07T10:16:17.000Z

@RichardWallis - thanks for the clarification on memberOf vs parentOrganization.

The suggested accommodation types are derived from RESO Data Dictionary 1.5 - PropertySubTypes enumeration. RDD is the standard used by US MLSs, which represents a significant volume of potential data, so I wanted to make it easy for publishers to include this property without having to apply logic.

Answer 89 · 2016-11-07T17:02:36.000Z

@dduran1967 - I appreciate the motivation of pulling these values ad hoc from RESO. My concern is for those who geographical or other reasons may want to use other accommodation types that are not part of your list.

If these become a set of Enumeration subtypes that only include RESO values, it may be difficult to accommodate these non-RESO aligned users.

At least initially, I am inclined to suggest that the property (typeOfAccomodation ?) be defined with a rangeIncludes of Text & URL, with a note that example values would include those defined in RESO such as Condominium, MobileHome, Triplex, etc. Including URL would also indicate that links to external predefined values would also be acceptable.

Answer 90 · 2016-11-07T17:14:35.000Z

Have been following this for some time.
I agree with Richard.
Good thinking with RESO though.

Here in NZ we use house, townhouse, unit, apartment, flat, etc.
These terms haven't changed in a long time and more specific versions like
duplex are only used in free form text descriptions. Not really adding much
to the search experience.

A text field could still be populated by MLS software (which presents a
select list of values to American users) minimising typos and thus enabling
easy search engine indexing.

Cheers,
Karl

On 7/11/2016 7:02 AM, "Richard Wallis" notifications@github.com wrote:

@dduran1967 https://github.com/dduran1967 - I appreciate the motivation
of pulling these ad hoc rom RESO. My concern is for those who geographical
or other reasons may want to use other accommodation types that are not
part of your list.

If these become a set of Enumeration subtypes that only include RESO
values, it may be difficult to accommodate these non-RESO aligned users.

At least initially, I am inclined to suggest that the property
(typeOfAccomodation ?) be defined with a rangeIncludes of Text & URL, with
a note that example values would include those defined in RESO such as
Condominium, MobileHome, Triplex, etc. Including URL would also
indicate that links to external predefined values would also be acceptable.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJtYWyzliY8iL1QmjlvV43MXKMmo3ILVks5q71m4gaJpZM4DVNjU
.

Answer 91 · 2016-11-07T18:08:43.000Z

I know this is a can of worms, but "SingleFamilyResidence" is already
there. Since it doesn't cover the dataset of the publishers I'm trying to
enable, I felt obliged to provide types in the same manner.

I looked at other lists like
https://en.wikipedia.org/wiki/List_of_human_habitation_forms which was
mentioned in the accommodations ontology, but it's too comprehensive. The
RESO list is broad enough to cover the diversity of the US market, but
narrow enough to be useful as a query filter - and in certain markets this
can be important to buyers and sellers.

On Mon, Nov 7, 2016 at 9:05 AM Richard Wallis notifications@github.com
wrote:

@dduran1967 https://github.com/dduran1967 - I appreciate the motivation
of pulling these ad hoc rom RESO. My concern is for those who geographical
or other reasons may want to use other accommodation types that are not
part of your list.

If these become a set of Enumeration subtypes that only include RESO
values, it may be difficult to accommodate these non-RESO aligned users.

At least initially, I am inclined to suggest that the property
(typeOfAccomodation ?) be defined with a rangeIncludes of Text & URL, with
a note that example values would include those defined in RESO such as
Condominium, MobileHome, Triplex, etc. Including URL would also
indicate that links to external predefined values would also be acceptable.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#241 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADvVmwYZRUbVO5FGkid4CdBIdN78rILlks5q71m4gaJpZM4DVNjU
.

Answer 92 · 2016-11-14T18:55:37.000Z

Hello,

I'm also a RESO member and interested in getting some consensus on how schema.org markup can be added to our virtual tours (property listing pages), real estate agent profile pages, and real estate office profile pages.

I've been tracking this conversation and have a few comments.

Dedicated properties that capture a count of bedrooms and bathrooms (i.e. numberOfBedrooms and numberOfBathrooms proposed by @dduran1967 ) are essential for us.

More crucially, is the fact that the Accommodation schema.org top level class is only (as Dave mentioned) roughly equivalent to real estate or property. In particular, the background page for hotel markup seems to suggest that an accommodation is

the actually relevant units of the establishment (e.g. hotel rooms, suites, apartments, meeting rooms, camping pitches, etc.)

However, the high-level RESO property types include Land for sale / lease. These do not have units or structural sub parts, but still are listed as property and often physically characterized primarily by acreage and square footage.

It seems that the Accommodation class would not be well-suited for this.

I think a solution that would support all the property types, including those that accommodate living spaces, but may not necessarily be structured and have units, would be something like this (using Dave's first example):

{
"@context": "http://schema.org",
"@type": "RealEstate",
"numberOfBedrooms": "4",
"numberOfBathrooms": "3",
[...]
"hasPart": {
"@type": "Accommodation"
[...]
}
}

I.e., a top-level RealEstate class that is a Place and whose instances have accommodations as a part, are owned by an entity, and are the itemOffered by a RealEstateAgent, etc.

This is motivated by the following english-language definitions of the terms property and real estate:

American heritage defn. of property:

a) Something owned d) Something tangible or intangible, such as a claim or a right, in which a person has a legally cognizable, compensable interest

Merriam-webster defn. of property:

something owned or possessed

American heritage defn. of real estate:

Land, including the resources in and on it, and the buildings and permanent fixtures attached to it.

Merriam-webster defn. of real estate:

property consisting of buildings and land

I have highlighted the word land in the definitions, demonstrating why I think the term accommodation may not be appropriate for a property type hierarchy that covers all the major use cases relevant for real estate data.

The definitions suggest that there is a general term "property" (something owned) and a subclass "real estate" that specifically refers to the land and structures. This latter term should probably be the top-level class to facilitate representing data about real estate.

Then the additionalType mechanism can be used to specify the kind of property it is, using the RESO Property Type and Property Sub Type enumerations, for example.

@RichardWallis if an accommodation type list comprises terms from an enumeration standardized by most of the Multiple Listing Services in North America (which will be the case if coordinated with what RESO is doing), I think this will sufficiently cover the major use cases.

I would be curious to see examples that are not covered and would be problematic for non-RESO aligned users, as it would be good to provide as feedback to the RESO Data Dictionary standardization effort.

This (along with Dave's suggested framework) completely meets all the representation needs to be able to markup the virtual tours of our partners in this way.

Answer 93 · 2016-11-23T18:58:12.000Z

While deploying the JSON-LD vocabulary suggested here on real estate agent pages like this (see this one for example):

I discovered that the image property is a required field on RealEstateAgent instances, causing the Structured Data Testing Tool to raise an error:

We have pages such as the one above on over 523K active real estate agents and we get images for agents wherever available in their Multiple Listing Services. However, I doubt that up to half of them have portraits available. The fact that this is an error and not a warning suggests that the JSON-LD would not be considered well-formed, preventing us from including structured data in their profile pages.

Is there is a reason why this is a required field? I can image other attributes of real estate agent instances that should be required, but I don't think an image should be required.

Answer 94 · 2016-11-23T19:01:43.000Z

@chimezie - schema.org does not require any properties. Feedback and discussion of Google-specific products, features and tools belongs elsewhere - https://productforums.google.com/forum/#!categories/webmasters/structured-data in this case.

In brief, don't worry too much about that kind of complaint from the Google SDTT, all it means is that some particular feature isn't finding enough markup to trigger. Other uses of the data aren't affected. If there is a more structural problem with your JSON-LD markup e.g. bad syntax, that ought to be reasonably clear.

Answer 95 · 2017-04-27T08:46:56.000Z

I've been tracking this conversation for a while as I am creating an open source property listings website builder ( https://github.com/etewiah/property_web_builder ) and I'd like it to follow some sort of standard.

Today I came across this which for me is the most useful resource I have come across so far so I thought I might as well share it here. A clear definition in JSON of the data-dictionary fields which makes it super easy for me as a Ruby / JavaScript dev to use:

https://github.com/Retsly/data-dictionary/blob/master/lib/property.json

Answer 96 · 2017-06-22T16:29:57.000Z

Love this entire post - especially feedback from MLS execs.

I've been looking for solid real estate markup for 2+ years now. I expected Zillow to take the lead more than it appears they have since they are fast to move... but nothing other than what I can tell is their use of "SingleFamilyResidence" and perhaps some basic rental markup.

So I hope you guys have been able to nail this new spec down @dduran1967 (another Dave!)... but in the mean time, as a brokerage in PA, we are trying to incorporate this markup to our listing pages and can't seem to get it past the error snippet tool throws. Any feedback based on the latest specs above would be helpful - as we now have them live on our site for listing detail pages and would love your guidance and feedback.

Real Estate Website: https://hmsre.com/
SAMPLE:
https://hmsre.com/listing-details/listing-6989736-5839-worthington-rd-doylestown-pa-18901/

{
 "@context": "http://schema.org",
 "@type": "SingleFamilyResidence",
 "additionalProperty" : "Subdivision: NONE AVAILABLE",
 "numberOfBedrooms"  : "6",
 "numberOfBathrooms" : "4.0",
 "floorSize": {
   "@type"    : "QuantitativeValue",
   "value": "4701"
  },
  "address": {
      "@type": "PostalAddress",
    "streetAddress" : "5839 WORTHINGTON RD",
     "addressLocality" : "DOYLESTOWN",
     "addressRegion" : "PA",
     "postalCode" : "18901"
 },
"@type"              : "Offer",
 "businessFunction"   : "http://purl.org/goodrelations/v1#Sell",
 "price": "",
    "priceCurrency": "USD",
     "name": "5839 WORTHINGTON RD MLS:6989736",
 "validFrom": "2017-05-23",
 "description": "Hidden a few minutes from Doylestown Borough, West Wind Farm is this classic Bucks County farmstead complete with stone house, guest house, ...",
        "image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg",
"image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg",
  "url": "https://hmsre.com/listing-details/listing-6989736-5839-worthington-rd-doylestown-pa-18901",
"itemOffered": {
 "@type"             : "SingleFamilyResidence",
 "numberOfBedrooms"  : "4",
 "numberOfBathrooms" : "3",
 "floorSize": {
   "@type"    : "QuantitativeValue",
   "value": "4701"
  },
  "address": {
     "@type"           : "PostalAddress",
     "streetAddress" : "5839 WORTHINGTON RD",
     "addressLocality" : "DOYLESTOWN",
     "addressRegion" : "PA",
     "postalCode" : "18901"
 }
  },
"offeredBy": [{
   "@context"  : "http://schema.org",
   "@type"     : "RealEstateAgent",
   "name"      : "Home Marketsite Realty",
    "image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg",
    "url"       : "https://hmsre.com",
   "telephone" : "866-502-5478",
   "email"     : "info@hmsre.com"
  }]
}

Please send over any feedback on the above. Currently I get 7 ERRORS and 2 WARNINGS from Google.

ERRORS
additionalProperty
Subdivision: NONE AVAILABLE (The property additionalProperty is not recognized by Google for an object of type Offer.)
numberOfBedrooms
6 (The property numberOfBedrooms is not recognized by Google for an object of type Offer.)
numberOfBathrooms
4.0 (The property numberOfBathrooms is not recognized by Google for an object of type Offer.)
floorSize
The property floorSize is not recognized by Google for an object of type Offer.
address
The property address is not recognized by Google for an object of type Offer.
numberOfBedrooms
4 (The property numberOfBedrooms is not recognized by Google for an object of type SingleFamilyResidence.)
numberOfBathrooms
3 (The property numberOfBathrooms is not recognized by Google for an object of type SingleFamilyResidence.)

WARNINGS
address
The address field is recommended. Please provide a value if available.
priceRange
The priceRange field is recommended. Please provide a value if available.

I am very well versed in MLS data with close to 15 years experience and multiple MLS Boards across the US (dealt with 25 of them several years back) - yeah, kinda a geek - so I understand RETS standards and how painful it has been to normalize this data. That being said, I am really shocked this has not been standardized yet. Should have been attempted before recipes in my opinion since we can all agree to the basics for both residential, commercial, resale/sale and lease/rent. So hoping this can be agreed upon soon.

I appreciate your feedback as we try to get our site data structured better for Google and future home buyers to our website.

Dave
Founder & Real Estate Tech Guru
https://hmsre.com

Answer 97 · 2017-06-23T11:25:26.000Z

I am not able to provide a complete review of your markup, but can give a few hints: 1. Try to understand the model for accommodations at http://schema.org/docs/hotels.html The only difference between real estate and hotels markup is in the business function in cases of sales. 2. additionalProperty belongs to the schema:Product, not the schema:Offer. See http://schema.org/PropertyValue for many examples. You can also use the more specific property http://schema.org/amenityFeature when you want to indicate availability times (like frontdesk times in gated communities). http://schema.org/LocationFeatureSpecification also has examples that might fit your domain. Martin

…

----------------------------------- martin hepp http://www.heppnetz.de mhepp@computer.org @mfhepp

On 22 Jun 2017, at 18:30, Dave Geipel ***@***.***> wrote: Love this entire post - especially feedback from MLS execs. I've been looking for solid real estate markup for 2+ years now. I expected Zillow to take the lead more than it appears they have since they are fast to move... but nothing other than what I can tell is their use of "SingleFamilyResidence" and perhaps some basic rental markup. So I hope you guys have been able to nail this new spec down @dduran1967 (another Dave!)... but in the mean time, as a brokerage in PA, we are trying to incorporate this markup to our listing pages and can't seem to get it past the error snippet tool throws. Any feedback based on the latest specs above would be helpful - as we now have them live on our site for listing detail pages and would love your guidance and feedback. Real Estate Website: https://hmsre.com/ SAMPLE: https://hmsre.com/listing-details/listing-6989736-5839-worthington-rd-doylestown-pa-18901/ <script type="application/ld+json"> { ***@***.***": "http://schema.org", ***@***.***": "SingleFamilyResidence", "additionalProperty" : "Subdivision: NONE AVAILABLE", "numberOfBedrooms" : "6", "numberOfBathrooms" : "4.0", "floorSize": { ***@***.***" : "QuantitativeValue", "value": "4701" }, "address": { ***@***.***": "PostalAddress", "streetAddress" : "5839 WORTHINGTON RD", "addressLocality" : "DOYLESTOWN", "addressRegion" : "PA", "postalCode" : "18901" }, ***@***.***" : "Offer", "businessFunction" : "http://purl.org/goodrelations/v1#Sell", "price": "", "priceCurrency": "USD", "name": "5839 WORTHINGTON RD MLS:6989736", "validFrom": "2017-05-23", "description": "Hidden a few minutes from Doylestown Borough, West Wind Farm is this classic Bucks County farmstead complete with stone house, guest house, ...", "image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg", "image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg", "url": "https://hmsre.com/listing-details/listing-6989736-5839-worthington-rd-doylestown-pa-18901", "itemOffered": { ***@***.***" : "SingleFamilyResidence", "numberOfBedrooms" : "4", "numberOfBathrooms" : "3", "floorSize": { ***@***.***" : "QuantitativeValue", "value": "4701" }, "address": { ***@***.***" : "PostalAddress", "streetAddress" : "5839 WORTHINGTON RD", "addressLocality" : "DOYLESTOWN", "addressRegion" : "PA", "postalCode" : "18901" } }, "offeredBy": [{ ***@***.***" : "http://schema.org", ***@***.***" : "RealEstateAgent", "name" : "Home Marketsite Realty", "image": "https://hmsre.com/HMSRE-LOGO-SQ-SM.jpg", "url" : "https://hmsre.com", "telephone" : "866-502-5478", "email" : ***@***.***" }] } </script> Please send over any feedback on the above. Currently I get 7 ERRORS and 2 WARNINGS from Google. ERRORS additionalProperty Subdivision: NONE AVAILABLE (The property additionalProperty is not recognized by Google for an object of type Offer.) numberOfBedrooms 6 (The property numberOfBedrooms is not recognized by Google for an object of type Offer.) numberOfBathrooms 4.0 (The property numberOfBathrooms is not recognized by Google for an object of type Offer.) floorSize The property floorSize is not recognized by Google for an object of type Offer. address The property address is not recognized by Google for an object of type Offer. numberOfBedrooms 4 (The property numberOfBedrooms is not recognized by Google for an object of type SingleFamilyResidence.) numberOfBathrooms 3 (The property numberOfBathrooms is not recognized by Google for an object of type SingleFamilyResidence.) WARNINGS address The address field is recommended. Please provide a value if available. priceRange The priceRange field is recommended. Please provide a value if available. I am very well versed in MLS data with close to 15 years experience and multiple MLS Boards across the US (dealt with 25 of them several years back) - yeah, kinda a geek - so I understand RETS standards and how painful it has been to normalize this data. That being said, I am really shocked this has not been standardized yet. Should have been attempted before recipes in my opinion since we can all agree to the basics for both residential, commercial, resale/sale and lease/rent. So hoping this can be agreed upon soon. I appreciate your feedback as we try to get our site data structured better for Google and future home buyers to our website. Dave Founder & Real Estate Tech Guru https://hmsre.com — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Answer 98 · 2017-06-23T14:29:20.000Z

A couple of things:

There is a missing '}' someplace, so the Offer is getting embedded in the first SingleFamilyResidence entity, which is confusing the Google parser.
There was a lot of debate about what is a bedroom and what is a bathroom, so we tabled those for now and left the generic http://schema.org/numberOfRooms. If you change your markup to something like the following, the Google parser recognizes the property:

 "numberOfRooms"  : [
   {
      "@type": "QuantitativeValue",
      "unitText": "Bedrooms",
      "value": "4"
    },
    {
      "@type": "QuantitativeValue",
      "unitText": "Bathrooms",
      "value": "3"
    }],

Answer 99 · 2017-06-23T15:11:54.000Z

Yes, that is how we ended up having to embed bedroom, bathroom, and square foot data in our virtual tours:

See (for example):

https://search.google.com/structured-data/testing-tool#url=http%3A%2F%2Fstaging.propertypanorama.com%2Finstaview%2Fris%2F1136427

Where we have:

{
"@type": "SingleFamilyResidence",
"address": {
"@type": "PostalAddress", "addressLocality": "[...]", "addressRegion": "[...]",
"postalCode": "[...]", "streetAddress": "[...]"},
"floorSize": { "@type": "QuantitativeValue", "unitCode": "FTK", "value": "1960"},
"name": "[...]",
"numberOfRooms": [
{"@type": "QuantitativeValue", "unitCode": "Bathrooms", "value": 2},
{"@type": "QuantitativeValue", "unitCode": "Bedrooms","value": 3},
{"@type": "QuantitativeValue", "unitCode": "Full Bathrooms", "value": 2}]
}

We use the unitCode to distinguish between 'Full Bathrooms' and the (problematic) decimal value often used by MLSes to represent the combination of full and 'partial' bathroom counts. For example, 2.5 would be 2 full baths and a half bath.

Unfortunately, the numberOfRooms is only available for instances under the Accommodation hierarchy, which needs to be reorganized to better support real estate property types. This leaves out instances of the Residence, which is often the only place in Schema.org where a large number of the property types we come across can be placed due to the lack of coverage by this hierarchy.

I mentioned some changes (in an earlier comment) that can be made to better support the various, mostly standardized categories of real estate property types that RESO is currently working on finalizing.

Answer 100 · 2017-06-23T17:16:35.000Z

Very nice @chimezie - helpful indeed. For the 2.5 baths, we have it loading in the bathrooms field as a 2.5 (if that's what the data holds) - but are you listing full baths in one and partial in another? Couldn't tell from your example either.

Thx @vholland - will have to track down my missing "}" in my example. I have a feeling I will be rewriting - already in the code as @mfhepp mentioned - my one field called "additionalProperty" because it's really intended to begin to load info into the graph (it's a server thing where I needed another field to load so the others will populate the fields). I resolved that by changing around some code.

Here's my latest based on everyone's input:
BreadcrumbList, SingleFamilyResidence and Offer
Example:
https://hmsre.com/listing-details/listing-7007696-1893-rampart-ln-lansdale-pa-19446/

Anyways, glad my schema markup is coming along... but still frustrated the committee and team keeps back-burnering this as it can be really powerful. For a response to say look at this (used for hotels, or rentals, etc) just shouldn't be used for general real estate - it's too large a category to not have been done right up front is all I am sharing. So all in favor of seeing a final approved spec go live. The MLS contains hundreds of valuable data points and we'd love to help graph the most important ones! Happy to provide additional data points here too of those most used. Whatever I can do to help. Thanks everyone.

Dave