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

[danbri]

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.

[thadguidry]

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)

[bshamblen]

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.

[mfhepp]

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:

1. 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.
2. 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.
3. Use schema:additionalProperty for all additional features of the real estate object that are not yet covered by schema.org.
4. 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"
                   } 
 }

[mfhepp]

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.

[ChiefRA]

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.

1. 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

1. 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

[mfhepp]

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

[ChiefRA]

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

[mfhepp]

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).

[ChiefRA]

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

[ChiefRA]

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

[mfhepp]

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

[jvandriel]

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)
.

[ChiefRA]

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

[ChiefRA]

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

[jvandriel]

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)
.

[danbri]

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.

[ChiefRA]

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.

[danbri]

@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!

[ChiefRA]

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.

[danbri]

@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.

[mfhepp]

Dave:

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.

I would like to clarify a few points in here: 1. Extending a Web-scale vocabulary like schema.org that shall be applicable for all kinds of cultural contexts and thousands of applications is quite a different thing than designing a conceptual data model in an industry ommittee-fashion, where you approximately know the usages of the data and the user community. The most important differences are that a) every new element in schema.org adds complexity and cost to the users of schema.org, in terms of searching the documentation, maintaining examples and validators, etc. b) even a simply addition can easily have side-effects across other parts of the vocabulary, like creating redundancies (e.g. we already have an element for the same meaning with just a different name), conflicts in the conceptual model (e.g. not reusing QuantitativeValue for quantititative properts or breaking the clear Agent-Promise-Object separation in the underlying GoodRelations model for offers), or blocking generic names for too narrow domain-specific purposes in the global name space. It is non-trivial to develop domain extensions from existing standards, and it is very different from dumping in an existing data standard, however elaborated that is. 2. Developing a fully-fledged extension proposal is a lot of effort. Having lead the accommodation and auto extensions and contributed to many others, I can tell you that a modest extension of ca. 20 types and properties is easily one person-year of effort, if you factor in all work on documentation and examples and the tedious (but important) process of discussing and polishing the submission. It also takes time - 1 - 1.5 years are reasonable. Now, the resources for this must come from somewhere. Most work on schema.org is done by volunteers or external domain experts. Sometimes they can work on extensions as part of ongoing projects, but most of the time, they cannot, and the people who have the expertise in this are often not the ones who want an extension badly. If the real estate industry wants this to progress, they could dedicate resources in terms of man-power or money to respective projects. As a starting point and to get used to the process: There are hundreds of schema.org elements that lack examples in at least some syntax. It is fairly straightforward to create such examples, make sure they validate, and submit them as pull requests in Github. 3. Many people want to extend schema.org because they want Google and other major search engines to give some preferential treatment to their content. This is a fallacy: An addition to schema.org is not directly linked to any effects in major search engines. You need to find stakeholders inside the big search engines who want to use your data structure, and you need a critical mass of data. The effort does not stop with adding a new type or property to schema.org, it's not even halfway, and neither a precondition (see below). Also, a new property or type is only needed if Google or any other major search engine *needs the distinction for a purpose*, not just because it gives a nicer model. If, for instance, Google had rich snippet type for real estate, it does not need 20+ types for specific forms of apartments or houses if the rendering algorithm for all of those is the same and if the relevance for a query can be determined from textual content. Extensions to schema.org are also not necessary if the information can be extracted in other ways, e.g. from HTTP prototol meta-data, media-object meta-data (e.g. in videos), or from tabular content in HTML. 4. You do not have to put everything into schema.org's core or hosted extensions: a) Anybody can develop and host an external schema.org extension. If this creates a critical mass of data, it's likely that major search engines will make use of that. See http://schema.org/docs/extension.html http://blog.schema.org/2016/02/gs1-milestone-first-schemaorg-external.html b) You can use unique identifiers for additional properties from external standards using the respective feature for schema:PropertyValue, which is http://schema.org/propertyID Like so: <!-- Product: Property ID for clarifying the meaning of a property: Code from eCl@ss Standard --> <!-- The Property code 02-AAM226 is for "USB interface present" in eCl@ss 8.1 --> <div itemscope itemtype="http://schema.org/Product"> <img itemprop="image" src="camera123.jpg" alt="" /> <span itemprop="name">Digital Camera 123</span> <div itemprop="additionalProperty" itemscope itemtype="http://schema.org/PropertyValue"> <span itemprop="name">USB Interface</span>: <meta itemprop="value" content="True">Yes <meta itemprop="propertyID" content="eclass81:02-AAM226"> </div> </div> The only thing you need to do is define a unique prefix for each version of your standard, like mls<nn>:. The same can be done for types with schema:additionalType: You can either define an HTTP or HTTPS namespace for your types, like http://mls.org/vocabulary/ then use the types to be more explicit about an entity, like so <div itemscope itemtype="http://schema.org/ABC"> <div itemprop="additionalProperty" itemscope itemtype="http://mls.org/vocabulary/CondoWithBeachfrontView"> Or, you can use URNs and define and register a URN namespace identifier (NID), see https://tools.ietf.org/html/rfc6648#section-4 Then you can use <div itemscope itemtype="http://schema.org/ABC"> <div itemprop="additionalProperty" itemscope itemtype="urn:mls:CondoWithBeachfrontView"> without the need to actually host definitions of your standard elements on a Web server (but also no opportunity to upgrade thereto later). By these straightforward and fully implemented mechanisms in schema.org, you can flexibly integrate any external type and property into you markup without validation errors etc. If there is enough data of that kind, search engines will care. If there isn't, they won't even if the types are in schema.org. No need to push things into schema.org in the hope of SEO effects. The amount of actual data is the bottleneck, and nothing else. This email is not meant hostile in any way, and I agree schema.org could do better in explaining such things. But there is just so little time and so much work to do. It really does not take much to contribute to schema.org by more examples, spotting mistakes, etc. AND submitting fixes as Github pull requests. So if your statement "Happy to provide additional data points here too of those most used. Whatever I can do to help. " can be read as such, that would be a good starting point. Best wishes Martin

[jaygray0919]

Thank you Martin!
This advice should be memorialized somewhere.
In the US, this commentary is equivalent to 'inside baseball' - how the game is played by professionals, not how the game is moderated by broadcasters or viewed by fans.

/jay gray

[DavidGeipel]

Thanks @mfhepp. That really was a GREAT response Martin.

I would love to see NAR come alongside your efforts to support this project. While I would love to add to the discussion and help put forward a list of required terms to help markup our content, I know they would also have a better overarching position.

Based on your note above, I will work a few contacts I have in the space and see what can be done to really take the bull by the horns. And yes, as much as you'd like to think this can work apart from the likes of a Google, it's so closely related because Google will want to adopt it if its widely implemented. That's something the MLS can do to help promote a standard but it also takes the industry a really long time to move since the MLS isn't national but regional.

Hope I can lean on you in the future to make and introduction or get some people moving forward with you and others here. Again, I just think as an industry, we (real estate industry) need to help lead and drive this one home (no pun intended based on your previous work here).

Hope to be back soon with some greater interest and response.

Dave Geipel

[RobLarsonCRMLS]

When you’re ready to work with the established MLS schema, the RESO Data Dictionary, I’m happy to assist. Rob Larson Chief Information Officer California Regional MLS T 909.859.2055 | C 909.263.1263 | E rob@crmls.org<mailto:rob@crmls.org> From: Dave Geipel [mailto:notifications@github.com] Sent: Monday, June 26, 2017 5:10 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) Thanks @mfhepp<https://github.com/mfhepp>. That really was a GREAT response Martin. I would love to see NAR come alongside your efforts to support this project. While I would love to add to the discussion and help put forward a list of required terms to help markup our content, I know they would also have a better overarching position. Based on your note above, I will work a few contacts I have in the space and see what can be done to really take the bull by the horns. And yes, as much as you'd like to think this can work apart from the likes of a Google, it's so closely related because Google will want to adopt it if its widely implemented. That's something the MLS can do to help promote a standard but it also takes the industry a really long time to move since the MLS isn't national but regional. Hope I can lean on you in the future to make and introduction or get some people moving forward with you and others here. Again, I just think as an industry, we (real estate industry) need to help lead and drive this one home (no pun intended based on your previous work here). Hope to be back soon with some greater interest and response. Dave Geipel — 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/AQn_gKvWPxoNSAM7zM2ekTjXnuJq4a7rks5sH9fRgaJpZM4DVNjU>.

[danbri]

Thanks for the positive discussion, everyone.

@RobLarsonCRMLS - perhaps now would be a good time to explore some concrete examples, and see how they look in both RESO and Schema.org representations. Would you have a few examples of RESO handy that could form the basis for this?

[RobLarsonCRMLS]

http://ddwiki.reso.org/ is the standard that NAR has mandated all MLSes support. This metadata is based on existing structures in MLS systems in the US and Canada. I’ve also attached our 1.6 version that is going live in July. We are finishing up the initial growth of the dictionary this year with our last group of field enumerations (lookups). The Data Dictionary workgroup is wrapping up that work over the next two months and you can have a preview of those enumerations around the October timeframe. 1.7 of the dictionary finalizes next spring and we are looking at adding new resources for Broker Back Office Systems, Membership Management Systems (i.e. Rapattoni, Ramco, etc.), Kill Resource, Lockbox Systems (e.g. Supra, SentriLock), and also resources for communicating business rules. Rob Larson Chief Information Officer California Regional MLS T 909.859.2055 | C 909.263.1263 | E rob@crmls.org<mailto:rob@crmls.org> From: Dan Brickley [mailto:notifications@github.com] Sent: Tuesday, June 27, 2017 1:22 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) Thanks for the positive discussion, everyone. @RobLarsonCRMLS<https://github.com/roblarsoncrmls> - perhaps now would be a good time to explore some concrete examples, and see how they look in both RESO and Schema.org representations. Would you have a few examples of RESO handy that could form the basis for this? — 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/AQn_gC4_9TLEwxeclgLO3Nvbg_-Pf35nks5sIPPTgaJpZM4DVNjU>.

[RESO-RETS]

Dan,
We would love to see the latest version of the RESO Data Dictionary that's about to be released publicly fully setup at schema.org for the benefits of the community. Is there a chance we can chat about this in detail via phone?
Thanks!
Jeremy

[mfhepp]

@RESO-RETS
Jeremy:
Are you proposing to
a) integrate RESO into schema.org,
b) develop examples of how to use RESO with the existing elements of schema.org (as I described above),
c) develop a hosted schema.org extension,
d) develop an external schema.org extension, or
e) mirror RESO in the schema.org namespace?

I am pretty convinced that b) is the best route for most detailed, industry-specific extensions. d) is second-best.

All the others are problematic if the external standard (e.g. RESO) are to remain an independently developed specification, because

• they require to modify the given standard, often significantly, to match the conceptual model and naming conventions of schema.org and will typically only work for a subset of the standard,
• you end up with two different versions of the standard with different paths of evolution, release cycles etc.

It is almost impossible to keep any external data standard deeply integrated with schema.org and externally managed. You can harvest and extract parts of a standard and contribute it to schema.org, but that virtually means the original standard will be abandoned or at least diluted.

I speak from experience - neither the automotive extension, nor the accommodation extension are imports from industry standards, but instead carefully crafted domain models to bridge between schema.org and such standards.

Martin

[chimezie]

@mfhepp, there are already many examples in this thread of forcing real estate data that can be represented as RESO into the current schema.org framework and because of the many limitations of doing so (which have also been discussed here), I think an externally-hosted extension may be the best first step.

It seems to me that we are beyond the point of needing use cases to define the basic problem. See comments from @dduran1967 for example.

[rvguha]

I think we should try for a hosted extension and if that is too difficult, an external extension. I strongly believe that a hosted extension is both possible and the best for publishers and consumers of this data. Please let us know how we can help. guha

…

On Mon, Jul 3, 2017 at 1:55 AM, chimezie ***@***.***> wrote: @mfhepp <https://github.com/mfhepp>, there are already many examples in this thread of forcing real estate data that can be represented as RESO into the current schema.org framework and because of the many limitations of doing so (which have also been discussed here), I think an externally-hosted extension may be the best first step. It seems to me that we are beyond the point of needing use cases to define the basic problem. See comments from @dduran1967 <https://github.com/dduran1967> for example. — 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/AFAlClLNdKY34kvn8E5NGw06pHrdet_Kks5sKKyfgaJpZM4DVNjU> .

[chimezie]

@rvguha , I think a very useful first step would be to extend the Schema.org class hierarchy in order to accommodate the property types defined in RESO, making sure to do so in a way that minimizes disruption to the existing hierarchy. I have attached a screenshot of an example OWL ontology that extends schema.org in an attempt to do this in order to address some of the issues.

The full OWL file It is available here . It is based on TopBraid's OWL version of schema.org, just for the convenience of modeling it in Protege.

The OWL file includes textual definitions from the 1.5 RESO Data Dictionary, for reference, as well as definitions from various dictionaries for common, high-level terms.

The image shows 5 points of extension and where classes are rearranged, which I'll explain here.

1. The ontology adds a Dwelling class, a concept which is common to many of the definitions of the property types in RESO and places it under the existing Accommodation class.
2. It places the existing Residence class under the new Dwelling class, giving it a more specific meaning under the Place hierarchy.
3. The existing House class is placed under the Residence class
4. The Property class, which is central to the concepts in RESO and existing MLS systems, is added at the top level to introduce the notion of ownership
5. The existing House class is placed under the Property class, extending its meaning to include ownership

The rearrangement of the House and Residence classes is mostly motivated by trying to support the notion of a dwelling, which is central to the RESO data dictionary terminology. A dwelling is a place to live and therefore has a more specific meaning than that of the Accommodation class, which is more general in order to include the concept of a meeting room (for example). It also supports the notion of a (residential) unit, which is also central to the RESO data dictionary terminology.

A Building class is also added as the more general concept of a 'structure' that a house is a specific kind of and is used for RESO definitions that characterize property primarily in terms of the makeup of their constituent parts (i.e., the residential units) for example: Duplex, Multi-Family, Quadruplex, Triplex, Condominium, etc.

[c6410]

i see good discussion going on above. any update on this now ? was it updated to latest schema ?

[shelkesays]

Thank you @danbri. There are a couple of websites which can benefit from these, like our own mycuteoffice.com. Where we are planning to add these schemas. Others which can make use of it are,

1. My Cute Office
2. Meetings and offices
3. Breathing Room
4. Shared desk
5. Workamp

Even we work will benefit from this.

[danbri]

@RESO-RETS Jeremy - would you still be available to chat about referencing the RESO data dictionary from Schema.org, and related improvements?

Also, where does https://www.retall.org/ (and MITS) fit into the landscape?

[ChiefRA]

Hi Dan and the Team, If this discussion is still available (regarding improving the Real Estate related items for Schema Markup) I would like to get involved. Do you have any drafts I can read and improve upon? Thanks, Arthur

…

On Wed, Aug 14, 2019 at 2:19 PM Dan Brickley ***@***.***> wrote: @RESO-RETS <https://github.com/RESO-RETS> Jeremy - would you still be available to chat about referencing the RESO data dictionary from Schema.org, and related improvements? Also, where does https://www.retall.org/ (and MITS) fit into the landscape? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#241?email_source=notifications&email_token=ADLMFD3JM7DKWGQTTX53ASDQEPS3BA5CNFSM4A2U3DKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4IPM3I#issuecomment-521205357>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADLMFDYBK7VLIFNRK3DXDS3QEPS3BANCNFSM4A2U3DKA> .

[martinmillerco]

Hi Dan and Team,

Is there anything that I or anyone else could do to help make this happen?

Best regards,
Brent

[danbri]

I would like to discuss integration with the RESO data dictionary (https://ddwiki.reso.org/display/DDW17) and MITS (https://www.retall.org/approved-mits-standards/).

For example, for type of real estate properties - it would be good to be able to reference somehow

• https://ddwiki.reso.org/display/DDW17/PropertySubType+Field (see under "Lookup Values? Click here to expand...")
• https://ddwiki.reso.org/display/DDW17/PropertyType+Field

e.g. as an enum in schema.org or left as a string with recommended values.

Another example (MITS), https://www.retall.org/wp-content/uploads/2019/04/Property-Marketing-ILS-4.1-Supplemental.html#type_GeneralAmenityType

[RichardWallis]

It's a shame that the RESO LookupID values don't appear to map to a URI.
eg. the LookupID (302002 ) for https://ddwiki.reso.org/display/DDW17/Boat+Slip could be something like https://reso.org/{something}/302002. They could be then used directly.

The retail.org stuff doesn't look as simple

[marcelolara10]

Hello everyone about improving Schema for Real Estate, I saw many comments and websites trying to implement in the correct way but many has lots of doubts.

Usually they create in the page many context Schema.org for example:

1. Schema.org - SingleFamilyResidence
2. Schema.org - Product and then Offer
3. Schema.org - Orgnization
   and so on.

When google and other service providers are reading some website that has Schema did they need to Schema to be one part for example:

1. Schema.org - Organization - SingleFamilyResidence - address - Product - Offer? If so how i do this? What works better and its correct?

Some website like Trulia and Zillow they dont aggregate all the Schema into one big Schema.
I say a website in this post trying to put all together but didnt work.

mabye redfin tried to use product and singlefamily together but i dont know if this works: https://search.google.com/structured-data/testing-tool?hl=pt-BR#url=https%3A%2F%2Fwww.redfin.com%2FFL%2FMiami-Beach%2F5980-N-Bay-Rd-33140%2Fhome%2F42784240

Example:
{
"@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"
}]
}

@RESO-RETS
@rvguha
@mfhepp

[github-actions]

This issue is being tagged as Stale due to inactivity.

[etewiah]

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

I've just started working on some updates to PropertyWebBuilder and pretty disappointed to find that this issue is not advancing. Is there anything I can do to help move this on?

Also disappointed to find that the retsly data-dictionary I referenced in my earlier post is no longer available. Anyone know if it has moved somewhere else?

[ChiefRA]

Hi all,
Since this is still an actual thing and will always be (Real Estate) I propose to start working on it and shed some light into complete integration.

This is how I see it:
1) Create a clear and complete Real Estate Property Type class hierarchy as a starting point, e.g.:

• Apartment
• Condominium
• Co-op
• Farm / Ranch / Plantation
• Fractional Ownership
• Hacienda
• Land
• Single Family Home
• Multi-Family Home
• Private Island
• Townhouse
• Other Residential
  and so on

(I've seen that @chimezie started to create such a document in this discussion at some point)

2) Create a clear and complete Real Estate Amenities class hierarchy:

• Bathrooms
• Bedrooms (Full or Half)
• Fireplaces
• Granite Countertops
• Hardwood Flooring
• Billiards Room
• Exercise Room
• Doorman
• Eco-Friendly (Green)
• Gardens
• Car Garage
• Barn
• Helipad
• Boat Slip
• Bowling Alley
  and so on

3) Review and complete if needed the Real Estate BusinessFunction (https://schema.org/BusinessFunction) in regards to the type of access you have on the Real Estate Property:

• Buy
• Sell
• Rental
• Lease
• Maintain
• Construction
• Repair
  and so on

@danbri if you agree with this, please let us know where to put all these documents to start with and what are the next steps to integrate this.

Thanks,
Arthur

[danbri]

There have been some real estate inspired improvements since this thread started, see https://schema.org/docs/releases.html Many were proposed by my colleagues at Google based on their investigations At this stage I don’t think we should go any deeper until some consuming application (from any non-research user-facing platform/service) engages in a way that can guide questions of vocabulary and scope. To go into the level of detail outlined here would be a major undertaking and difficult to do well internationally - it would probably be better to focus on alignment with existing codelists etc (and potentially reflect these into schema.org as enumerations)

…

On Sun, 21 Mar 2021 at 11:30, Arthur ***@***.***> wrote: Hi all, Since this is still an actual thing and will always be (Real Estate) I propose to start working on it and shed some light into complete integration. This is how I see it: *1) Create a clear and complete Real Estate Property Type* class hierarchy as a starting point, e.g.: - Apartment - Condominium - Co-op - Farm / Ranch / Plantation - Fractional Ownership - Hacienda - Land - Single Family Home - Multi-Family Home - Private Island - Townhouse - Other Residential and so on (I've seen that @chimezie <https://github.com/chimezie> started to create such a document in this discussion at some point) *2) Create a clear and complete Real Estate Amenities* class hierarchy: - Bathrooms - Bedrooms (Full or Half) - Fireplaces - Granite Countertops - Hardwood Flooring - Billiards Room - Exercise Room - Doorman - Eco-Friendly (Green) - Gardens - Car Garage - Barn - Helipad - Boat Slip - Bowling Alley and so on *3) Review and complete if needed the Real Estate BusinessFunction* ( https://schema.org/BusinessFunction) in regards to the type of access you have on the Real Estate Property: - Buy - Sell - Rental - Lease - Maintain - Construction - Repair and so on @danbri <https://github.com/danbri> if you agree with this, please let us know where to put all these documents to start with and what are the next steps to integrate this. Thanks, Arthur — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#241 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGM6P5PPZ3E62UGJW2TTEXKGTANCNFSM4A2U3DKA> .

[ChiefRA]

Hi @danbri ,

Thanks for the fast reply. I've seen all improvements that have been taking place around Real Estate.

What I was trying to do with my proposal, is to bring the Schema.org Structured Markup in line with the latest changes from within Real Estate, to enable Search Engines to better understand the entire Real Estate industry and to become the first consumers.

The Real Estate Structured Markup code is incomplete as of now and my opinion is that we are now patching things in order to show up in search as Rich Results in this vast field of Real Estate.

To take it one step further, we would like to see in search some Real Estate Rich Results customized like the Events are showing in search nowadays: https://www.screencast.com/t/cR2sSKkOb

If you guys want to take it one step further, count me in to further develop this part.
Thanks.
Arthur

[etewiah]

Please note that there is another open issue on this same topic here:

schemaorg/suggestions-questions-brainstorming#60

Perhaps we should close one of them and redirect to the other!