schemaorg
schemaorg copied to clipboard
Guidance or vocab needed regarding Real Estate (property purchase, rental etc.)
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.
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)
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.
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"
}
}
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.
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
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
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
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).
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
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
As I tried to explain, you have to attach the priceSpecification property to the offer, not to the residence.
Here's an example of what Martin means:
2015-09-02 16:55 GMT+02:00 Martin Hepp [email protected]:
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 https://github.com/schemaorg/schemaorg/issues/241#issuecomment-137112935 .
Thank you guys, I'll try to implement it now in this way.
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
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" [email protected] 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 https://github.com/schemaorg/schemaorg/issues/241#issuecomment-137126510 .
I have just closed https://github.com/schemaorg/schemaorg/issues/571 as a duplicate of this issue. If you didn't see it already, please take a look over the discussion there.
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.
@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!
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.
@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.
@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.
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
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?
@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.
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.
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. [email protected].
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.
And you can email [email protected] with questions about the EULA and acceptable use.
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.
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
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...