-
Notifications
You must be signed in to change notification settings - Fork 822
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Guidance or vocab needed regarding Real Estate (property purchase, rental etc.) #241
Comments
Zillow.com should REALLY get involved with this issue. Come on Zillow ! |
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:
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):
|
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 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.
How can we improve these? |
Hi Arthur: 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, 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, |
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, 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. |
Hi guys, I can't seem to find a correct implementation for a price of a Residence with the schema: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? |
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:
Some residence
$5,908,000
2015-09-02 16:55 GMT+02:00 Martin Hepp notifications@github.com:
|
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. |
Unfortunately those errors have nothing to do with the validity of the Google's validator has a bug that it doesn't recognize multi type entities
And as for the missing 'price' warning, this has to do with how Google I suggest you use the Structured Data Linter if you want to know if your Ps, my name is Jarno ;)
|
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. |
Thanks Jarno. @danbri Dan do you have any ideea when Google Structured Data Markup Tool will recognize and support multi type entities? |
@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. |
@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. |
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
|
Thank you Martin! /jay gray |
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 |
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>.
|
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? |
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>.
|
Dan, |
@RESO-RETS 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
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 |
@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. |
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>
.
|
@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.
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. |
i see good discussion going on above. any update on this now ? was it updated to latest schema ? |
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,
Even we work will benefit from this. |
@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? |
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>
.
|
Hi Dan and Team, Is there anything that I or anyone else could do to help make this happen? Best regards, |
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
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 |
It's a shame that the RESO LookupID values don't appear to map to a URI. The retail.org stuff doesn't look as simple |
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:
When google and other service providers are reading some website that has Schema did they need to Schema to be one part for example:
Some website like Trulia and Zillow they dont aggregate all the Schema into one big Schema. 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: |
This issue is being tagged as Stale due to inactivity. |
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? |
Hi all, This is how I see it:
(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:
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:
@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, |
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>
.
|
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. |
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! |
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.
The text was updated successfully, but these errors were encountered: