Last year, there were about 130 people at the RESO Spring meeting. This year, we had about 230 people, including many more brokers and vendors than in years past. There’s a lot of energy around the RESO meetings these days, and that’s very exciting! Following are some of the notes I took during the meeting.
The RESO meetings kicked off with no introduction, with attendees diving right into concurrent workgroup sessions: RETS 1.x, Data Dictionary, and Internet Tracking. Sadly, I could only be in one session at once, and chose Internet Tracking. Likewise, in the afternoon, I couldn’t attend both Transport and PUID at the same time and chose PUID.
This workgroup is focused on creating a standard for communicating user activity surrounding the listing. Proposed fields, descriptions of each field, and relevant enumerations are documented here. Fields were reviewed and discussed by the group. The concept (illustrated below) and XML examples are located here. Note that many fields will be optional to address local and legal requirements.
It was a group consensus that EventType “View” needs to be fleshed out and “Favorited” needs a negative version (like “Trashed” or something like that). Adding “Floorplans”, “Mortgage Calculator”, and “Showing Scheduling” might be other EventTypes to add. It may be also desirable to track “Saved Search” and “Agent Profile Views.”
Next steps will be to flesh out the proposal, using the ideas above and more, make a formal recommendation to the data dictionary, and publish a white paper on tracking method best practices. It’s possible that in the future, the workgroup may also consider creating functions for statistics and aggregate information.
Internet tracking is a topic I’ve written on at length:
Research and Development
The R&D Workgroup is the conduit for determining which business cases justify the involvement of RESO and the creation of standards. The group researches and develops aspects of the standard, and usually that work is then passed to another relevant workgroup for further development. Alternatively, standards R&D can start out in another workgroup, or the board can create a new workgroup to develop the standard.
The first item discussed was what standards and best practices could be put in place for the use of a single data feed for “authorization” purposes. A vendor:
- provides products and services to many subscribers
- uses the data feed for making sure that each subscriber is authorized for their products and services .
In this context, what best practices are needed so a vendor can legitimately use data downloaded once for multiple customers and needs, rather than using credentials for each customer to pull multiple copies down? The latter is a highly inefficient practice. This topic was initiated based on my 2014 blog post on the subject, Solving the RETS Credential Re-Use Conundrum. The goal now is to create a best practice document that may be included in the Council of MLS (CMLS) best practices. These practices include, for example:
- use of appropriate legal agreements
- having the agreement specify exactly what data uses are allowed
- ensuring customers are active MLS participants and, to that end,
- MLSs providing limited roster view to these vendors.
Also, vendors should provide a list of customers to the MLS, at least quarterly. In the future, work can be done to better describe (technically) what fields can be used for what products and services (IDX vs. VOW vs. Broker Back Office).
Other subjects: Images and Media – should the RETS data dictionary media resource include additional image metadata about, for example, image orientation or copyright? I suggested attending my presentation that would take place the following day, about “Listing Maintenance Business Rules.” We briefly described the effort to create an Organizational Unique Identifier (OUID) Update so the source of data could be described reliably. Finally, we reviewed the R&D project backlog; there are a lot of projects the group could prioritize and work on. I suggested we narrow the list a bit and survey the RESO membership to help prioritize items. Jeremy Crawford asked the group for any ideas they might have that could be solved with a standard or best practice document. One idea suggested was to come up with a floorplan data exchange format – maybe SVG – then systems could extrapolate room dimensions and other data. Another idea would be to create standards for agent ratings and agent experience. Would parties that currently store that information be interested in moving it around via RETS?
The goal of this group is to create a Property Unique Identifier. One approach considered has been to use location information to generate an ID. Another approach has been to mash up address and tax data to create an ID – but that approach doesn’t work either (counties recycle tax numbers, etc.). The current approach being considered is for RESO to create and maintain a unique identifier service. A user of the service would be able to send certain data and receive a likely property that matches with an ID and a confidence level for that match. This service would either be updated from tax record providers – or the service would (in turn) call on the tax provider’s database via API as needed. Currently RESO is evaluating CoreLogic, Black Knight, and Zillow for that tax provider role. This effort is still in the “discovery” phase, exploring what fields each vendor can provide and gathering details about their APIs.
Mike Wurzer brought up that many local markets gather better public records data than the national vendors can provide, and it may be ideal to get data from multiple sources. Not just public records, but also listings could be used for this purpose as well. Other people wondered if the accuracy and complexity of that approach would be acceptable, but it will be discussed. Someone else brought up the concern that we wouldn’t want to be dependent on one vendor. A good question: what happens if the system returns more than one PUID record with the same confidence level?
What combinations of data could be used to create a PUID? That’s an ongoing discussion! Should we use latitude and longitude with enough precision to differentiate between properties (the ECMA approach)? Or use USDOT’s approach – using the county’s tax ID? But, as mentioned above, sometimes those tax IDs are not unique and are reused within counties. How about grouping address, tax, and other information and hashing it? But what if there’s a small variation in address? Finally, we could consider using a data provider’s OID and property identifier to create a PUID. Lastly, creating a GUID of some type? I suggested considering Blockchain as an approach, reiterating a position taken by Mark Lesswing at the previous meeting.
Jeremy Crawford described the structure of RESO, including the board of directors, technical and marketing committees, and workgroups. He also laid out the 2016 Strategic Plan, which has the following components:
- Creation – including transport / web API, data dictionary, PUID, internet tracking, R&D, and payloads.
- Adoption – by the industry and standards certification
- Leadership – creating an industry leadership presence, creating solutions to support business needs, and increasing membership and participation.
RESO recently created the Payloads Workgroup. Real estate data is typically delivered as a package comprised of a set of data for a specific business need. The RESO data dictionary defines all the fields and their specific characteristics available to be included in a payload. The new workgroup purpose is to define payload categories based upon real estate industry business need and which fields are to be included in each payload category as specified within the RESO Data Dictionary. For example, there can be a CMA payload, an IDX payload, etc.
Membership has increased by 10%. There are now 487 RESO members. In 2015 there was 150% growth in the brokerage space and there are now 20 broker members. There are now 510 MLSs that are RESO certified, and these MLSs represent 1.1 million brokers and agents.
RESO has created a free online data dictionary testing and certification platform located at http://ddcert.reso.org. This tool lets you work out any certification problems before you even apply for certification. A web API certification platform is coming soon. RESO has also launched a new public website at http://reso.org and a membership system. The biggest improvements are having single sign-on and responsive mobile-friendly design.
The RESO Fall Conference will be in Nashville, TN – October 24-26, 2016. Registration is open!
Art Carter (CEO of California Regional MLS and RESO Chair) praised all of the folks contributing to RESO and making a difference. He was joined by a panel of board members to talk about the RESO strategic plan, including Rob Overman, Richard Renton, Rebecca Jensen, Cary Sylvester, and Michael Wurzer. Cary described the plan for Transport / Web API. The API is approved and RESO is working on a certification tool. Completion of the Update specification for the API is targeted for Q3. Art Carter talked about the plan for Data Dictionary. In Q2 version 1.5 will be released, and there’s a plan for future versions as well. 1.5 should be approved by the board in June. RESO is also working on a data dictionary Wiki. Rebecca talked about the plan for PUID – the property unique identifier. Rob Overman talked about Internet tracking – how we can understand activity and traffic on listings. That workgroup is trying to reuse an existing standard called Activity Stream. The group is defining the fields for tracking at the current time and is looking to wrap up by the end of the year. Rob also talked about Research and Development. That group is thinking about new challenges and directing RESO. The most important task for R&D has been creating a way to articulate the business rules. That will allow for flexible front ends on top of our databases. R&D is also working on best practice documents on various topics, and these will become part of CMLS’s best practice documents. Michael talked about the new Payload workgroup. The board prioritized that item in order to improve RETS adoption and usage. Adoption is the most important goal for RESO right now – if the standards we create are not adopted, they mean nothing. Outreach is a long term process. Rebecca talked about the certification program, run by Greg Lemon. The board is setting metrics to gauge success of that program. A lot of RESO’s budget is spent on creating the certification tools. The goal is to continue to raise the bar for certification. Art talked about the leadership role RESO has been taking and the RESO Ambassador program. These ambassadors are tasked with being the voice and face of RESO, selling the value of RESO in their space. There are volunteer opportunities for that program. Richard talked about creating solutions to meet business needs, and how participation is key. Brokers need to be encouraged to participate more. Cary talked about increasing membership, especially broker engagement. Helping brokers understand the value and importance of RESO to their own efforts is an important part of this. The fee schedule may need to be reevaluated. Renewal and retention will also be evaluated.
There’s a lot on RESO’s plate this year, and the board of directors requested feedback. Ed Newman suggested that RESO work to coordinate RETS Update with the Upstream API. Cary sits on the boards of Upstream and RESO, and promised coordination and support for the standard going forward. A broker brought up that MLSs that have been certified are not providing brokers access to a data dictionary resource. Art says to bring the specifics to the attention of Jeremy and he will inform NAR that the MLS is out of compliance. There may need to be a public shaming program (just kidding!).
RESO Standards for Inception to Specification
Paul Stusiak provided an overview of the process for how ideas become standards at RESO. Small changes occur in the individual workgroups (i.e., transport, data dictionary, etc.). For new and large ideas, business needs are sent to R&D where the idea is firmed up. Recommendations are sent from that group to the technical committee which forwards that information to the workgroups, or to the board if a new workgroup needs to be created.
For changes to the existing standard, there are change proposal documents (RCP) that can be submitted. Revised proposals are published, comments are made, and there is an electronic vote within the workgroup. That’s then sent to the technical committee where it’s reviewed for cross-workgroup impact. The technical committee then submits the change the board with the recommendation to adopt. The RESO board adopts the change into the standard.
Business Rule Panel
Marilyn Wilson led a panel of brokers talking about the difficulty of dealing with the myriad of MLS business rules. When prompted, the group provided “crazy” rule examples. One MLS doesn’t provide a listing agent email display – only phone is provided. A rule from one MLS that drives the brokers crazy is that the main photo needs to be the front of the house – but some properties (like a lake home) are better represented by a picture featuring the lake. Another broker brought up the rule saying they can’t commingle data from different MLSs. [Note: this rule changed recently!] Another issue is where overlapping MLSs don’t have standardized school district information, which makes aggregation difficult. Another non-NAR MLS won’t send the broker “sold” listing information.
One broker (Tom) talked about going from 40 to 83 MLSs for his brokerage. It takes a lot of engineering time to change the display to comply with all the different MLS rules. Then the MLSs change the business rules, which makes dealing with the changing rules effectively a full-time job. Sometimes there’s good notice of all of the changes with 60-day notice, but sometimes there’s not enough notice – it’s all over the map. Another broker who, like Tom, is in a lot of markets, talked about facing a lot of the same challenges. Another broker talked about the difficulty in getting data feeds – for example, an MLS that requires a paper agreement to be provided – not allowing emailed or faxed agreements. That slows them down. Having to “extract” data from MLSs does not make it feel like a partnership. MANY other examples of MLS rules and practices that drive the brokers crazy were provided!
Business Rule Syntax
I provided an overview of a set of proposed business rule syntaxes. The need for a standard notation for documenting and communicating real estate business rules was recognized by RESO several years ago, but a substantive effort was not initiated by the R&D workgroup until late 2015, when there was an increase in industry interest in this area. MLSs with well documented business rules can move to a new MLS system, add additional front-end, or integrate other software that requires use of business rules (e.g. Upstream, AMP), all without manual gathering of business rules and inaccurate results. Creating a standard for real estate business rules will result in smoother conversions, more software choice, and enhanced competition and innovation.
The proposed approach is to start with SBVR-compliant RuleSpeak™. Field tested since the 1990s, RuleSpeak is a well-documented business rule notation. Furthermore, RuleSpeak includes guidelines, syntax and patterns to express business rules effectively in “Structured English”. The “Structured English” notation is perfect for clearly and unambiguously expressing business rules, even apparently complex ones, in non-technical language using business vocabulary. A somewhat more constrained syntax that is a contraction of RuleSpeak, which I am calling “REBR,” is also proposed.
I will be providing a formal proposal document very soon, and the R&D Workgroup will meet in a few weeks to discuss it. We’ll see if the underlying assumption holds up – that the business rules need to be easily writeable by non-programmers – or if we’ll end up with other criteria that override that assumption and the proposed syntax will be replaced.
In the next session, Ashish Antal from MLSListings demonstrated his business rule engine’s web API for enforcing MLS business rules. Ashish leveraged BPMN and XPDL to accomplish his goal – something we will have to consider as part of the RESO business rule project.
Heather Petersen, head of Digital Transaction Management at DocuSign and Executive Director for the xDTM Standard Association, presented on a standard for secure transactions called xDTM (http://www.xdtm.org/). This standard covers security, privacy, availability, assurance, universality, scalability, interoperability, and validity.
We’ll see if the industry has the stomach for this standard, since among other requirements, to be compliant, folks using transaction management systems would need to log in over an encrypted VPN using multi-factor authentication!
Unfortunately, I had to leave the event at the end of the second day, so that’s all I have for you. Presentations, including those from the third day, should be available on reso.org soon.
Share this post: