Note from the Editor: The recent 2015 Real Estate Standards Organization (RESO) Fall Conference dealt with the very complex real estate data issues, and it was quite the illuminating event.
We urge anyone that cares about the flow of real estate data, its reliability, and its accuracy, to read Matt Cohen’s 2015 recap in his own words below (an excerpt from his much longer summary) and consider getting involved in RESO.
2015 was an intensely busy year for RESO
The RESO Fall Conference in Austin, Texas was intensely busy this year, as the pace of both standards development and certification has accelerated. In 2015, RESO delivered the Data Dictionary v1.4, a data dictionary wiki, a Data Dictionary certification program and MLS Data Dictionary certifications, the Web API v1.0.2, updated transport certification platforms, vendor transport certifications, and an organizational unique ID.
In addition, RESO worked on industry leadership presence and outreach, and membership growth. Those are a lot of accomplishments, and the pace will continue in 2016!
RESO now has 227 members, up from 126 members in 2014. That’s 80% membership growth for the year to date! 58% of member organizations are MLSs, 31% are vendors, 9% brokerage, other associations are 1%, and NAR itself is 1%.
Jeremy Crawford, RESO’s Executive Director, provided attendees with a crash course in the RESO organization, and explained how RESO members can get involved with standards development.
Jeremy laid out the path for getting new ideas funneled through the Research & Development group, into an existing work group (e.g. Dictionary, Transport, RETS 1.x, PUID, Internet Tracking), through review of the Technical Committee, through the Board of Directors, to publication and compliance. If you want standards to improve, there is plenty of opportunity to get involved.
Great presentation by CRT
Chad Curry, Chris Coté and Dave Conroy from CRT presented about the Internet of Things in real estate and their new “CRTLabs” project, which will enable CRT to experiment with “things” rather than just with software and technical practices.
The Internet of Things will enable NAR members to improve the quality of life for everyone. Using sensors for CO2, temperature, energy, and light, people can monitor and create better living environments. This type of dynamic data could supplement the static data that is input into the MLS.
Perhaps as a closing gift agents could provide an environmental sensor system and other smart items that improve the buyer’s quality of life. Such gifts could help redefine the relationship of agents with buyers, outside of the transaction.
CRT is partnering with universities, NGOs, and vendors on its Internet of Things initiative. Ideally some of these items could become member benefits, and members could act as a focus group around some of these products. CRT is also working on security initiatives to help both vendors and homeowners manage security around the Internet of Things.
Chris Cote described OpenADR (automated device response) – a system under development that will help utilities maintain grid reliability and help customers control their energy future.
He also gave us a peek at “Rosetta Home” – open source software that CRT is developing to gather data from various sensors and give a consumer a dashboard view into all the different kinds of data that can be created about their home environment.
Finally, Chris described the “Array of Things” – city wide networks to measure air quality, traffic counting, heat, standing water, and so much more. Dave Conroy demonstrated “Rosetta Home,” showing how the Internet of Things data could be powerfully integrated into an MLS listing report. Hopefully, members can become a resource on home environment and monitoring for homeowners and homebuyers, and thereby help enhance their communities.
The Department of Energy
The Information Exchange Models Working Group met to track concepts and clarify common definitions, data sets, and transfer methods for applying home energy information to real estate use cases.
The group discussed how to overlay the Building Energy Data Exchange Specification (BEDES, pronounced “beads”) overlay on top of RESO’s standards.
The Data Access and Security Working Group met to identify barriers and seek joint solutions related to permissions and legal issues in sharing home energy information and best practices in keeping data secure.
There are three approaches to leveraging BEDES, and RESO can evaluate using one or more of the following: including BEDES energy related fields in the RESO Data Dictionary, mapping our terms and BEDES’s terms, and/or using BEDES terms as “synonyms” in our data exchange formats.
The group will continue to publish new mappings to serve as a “Rosetta stone” for BEDES and our standards to encourage adoption, and it will continue to support mashups of the data. Click for more information on BEDES.
R&D Work Group
This work group examines the business cases for RESO taking on new work and, at least to some extent, vets the technical aspects of those potential projects. As described earlier, R&D is the “funnel” for getting big new ideas into RESO standards. Following are some of the items we discussed:
Multifamily Information and Transaction Standards (MITS Standards). The MITS standards mostly relate to apartment and multi-family properties, especially property management. It could be an interesting supplement to RETS efforts.
RESO has been asked if it is interested in bringing this set of standards under the RESO organization. The work group believes this is a good idea and has suggested that additional legal and other diligence be performed. Click for more about the MITS standards.
Organizational Unique ID (OUID). This effort is about having a consistent way to refer to organizations in our industry, especially data sources such as MLSs, vendors, boards, and associations. It could be extended to franchisors, brokers, content providers, appointment systems, lockbox companies and more.
It could be a valuable part of helping listing aggregators de-duping or stacking listings. From a systems integrator perspective, having multiple parties referring to MLSs and other parties the same way is also useful.
Such an identifier could also be used to manage the chain of listing provenance documentation – to know the true source of data and steps between them and an aggregator/portal, especially if the aggregator/portal gets it from several sources.
RESO has collected vendor/MLS organizational information in a spreadsheet and is working on creating a unique ID for each.
The group discussed how to make it more manageable and how to best expose this data in a more programmatically useful format. Perhaps a push notification of changes? Or a way to pull it via RETS? The primary action item recommended is that the OUID become a part of the data dictionary and certification. Second, it must be made manageable online. Third, RESO must create a better way to consume the information than the current spreadsheet.
Media. Creating additional information around the images transported by RESO standards could enable consumers of those images to use them more easily and effectively.
There is some interest in creating standards for tagging images by size (e.g. thumbnail, medium, large, best…), as well as a more standardized way of describing what part of the property is being portrayed in an image. Other possible fields include orientation, aspect ratio, white padded, cropped, branded and more.
Most of these ideas have not been prioritized by the workgroup, but there is definitely a desire to send information around copyright and licensing along with the image. That initiative may be taken further by the data dictionary workgroup, considered in consultation with RESO’s attorney, Mitch Skinner. In the future we might look at how to address video and stitched image formats (walkthroughs, etc.).
Using One Login for Multiple Feeds. There’s a need to promote a best practice to expose active user-ids and statuses to vendors so they can ensure they don’t misuse data across their customers, when for efficiency’s sake they download data once for multiple MLS-approved customers and uses.
Since there seems to be sensitivity at some MLSs to providing the roster resources to some vendors, potentially the group could recommend creating a subset of the roster resource that is more limited than the roster – just agent ID / name, office identifier, and status.
I suggested that we could create a system for vendors to use a ‘vendor account’ associated with non-interactive accounts with their associated privileges (as unpacked better in my 2014 blog that initiated this whole topic) – but this adds complexity.
There’s also a discussion of providing a way for someone pulling RETS data to know what’s usable for different usages (IDX, VOW, back office, etc.), which is a bit of a different issue that requires more discussion.
At the work group meeting I brought up the need to re-engage on the subject of creating a means for RESO standards to document and transmit MLS data business rules, so that vendors can easily obtain all of the more complex business rules from an MLS to facilitate data updates and system transitions.
This is something I documented thoroughly for the group in 2010 and have brought up a few times since. The need for it continues to grow and become more urgent. The new work group chair, Greg Moore, understands the need to get this going, so I have some hope that RESO will move forward on this initiative.
Property Unique Identifier (PUID) Work Group
Having a Property Unique Identifier (PUID) for each property is useful for all sorts of reasons – de-duplication (for MLSs vendors, websites, etc.), aggregation (tying to mash up multiple sources), fraud prevention (uniqueness of mortgage contracts), property history reports / CDOM (even if the address has a “typo” in it), and Internet Tracking (providing value to MLSs, vendors, brokers, agents…).
The original thinking was that, to solve this problem, we could simply “slap a few fields together” to generate an identifier. It’s still a possibility. But, that might only work for 95% of the cases.
There are lots of cases where we don’t all have the data at hand reliably, and even APNs (tax IDs) are sometimes re-used or never assigned to begin with. Could we step back and use other pieces of information – things that MLSs have in their database?
For example: formula fields (tax fields, unit number, etc.), geography (i.e. lat, long, elevation, entry level, etc.) and address information (city, country, county or parish, postal, street related fields, lot size, etc.)?
Rather than generating a simple unique ID – or in addition to it – we could create one field where we concatenate a bunch of other fields and we can create a “compare PUID” function, where even if a property is missing one part of the field or has some parts that are not quite the same, we could determine how likely it is that the properties are one and the same.
We need to consider what the algorithm for this might be; then we can create pseudo-code and potentially a reference implementation. Perhaps there could be a web API that calls this implementation, although there is a concern that this latter approach is too “Rube Goldberg.”
Theoretically we could also then generate a smaller PUID that refers to this concatenated field in some way. Mark Lesswing also suggested we look at the financial industry’s use of “block chaining”, and employ it as a PUID mechanism.
Internet Tracking Work Group
This is a brand new work group that is focused on creating standards for moving data related to online activity – for example, how many people have viewed a listing, on what sites, how they got to that listing, and how they interacted with that listing.
Once standards are created, it will be far easier to compile a better and comprehensive picture of what is happening around listings online.
This group’s main activity during this meeting was to start to lay out some of the business cases for the different kinds of information that should be standardized. Chris Lambrou, the chair of this group, made a presentation to the technical track attendees to describe what the group is doing.
The group has identified stakeholders: who will take this data and how will they use it (i.e., what are the business use cases)? This drives what fields are needed to support those use cases.
The group will also look at current solutions, from Zillow to SourceMLS, to find a standard that will work for everyone.
Transport Work Group
The main activity for the group during this meeting was to discuss compliance requirements for the new Web API under development. No doubt the output of this meeting will be documented for wider release, as we are quickly moving toward a time when MLSs and their vendors will need to know a lot more about transport compliance, since it is NAR-mandated for mid-2016.
RETS 1x
A panel presented its experience with RETS 1x data dictionary compliance. The question was whether to do a native mapping, rename existing fields to the data dictionary names, or map through a proxy to avoid making local changes.
Rob Larson said that he’s using both: a proxy that “gets him in the door” – that allows people to use the new while he transitions the current database and forms to the new dictionary terms, and while he transitions RETS users to native dictionary use.
Rick Trevino is changing what’s happening in the background to use the dictionary, but is not changing input forms or reports.
Richard Renton is using CoreLogic Trestle as a proxy, which gave him instant certification, but he’s also working with Bridge Interactive as well. Richard brought up some of the complexity that can attend compliance – for example, his MLS doesn’t – by rule – publish square footage, which is a core field in the data dictionary. So, compliance can be more than a technical endeavor.
Nonetheless, Rob made a great point: that if you don’t have data for a field – even a “core” field – you don’t have to add the field to be compliant. Paul Stusiak presented further about RETS 1.x to the larger meeting, explaining the history of 1.x all the way to the current version, 1.8.1, along with the changes made in each version.
In closing:
This was a busy conference and it was great to see such great participation this year from over 230 attendees. If you’re not already a RESO member, I would strongly recommend becoming one and attending the conference!
#RESO
