Conversations about the MLS industry, creating software, and employee ownership.

I attended a presentation from Dale Ross and Marty Frame to a variety of MLS and public records software vendors last Sunday at the NAR Convention in San Diego.  Here are a few points I took away from the Q&A session:

• No Focus on Data Standards for MLSs.  In response to my question as to whether RPR would be promoting a data standard for MLSs, Marty said something like they didn’t want to be a RETS enforcer.  I’m not completely sure what that means but if Marty intended for RPR to help with data standards, he likely would have said so.  Instead he said it wasn’t part of their plan and they’re primarily focused on about 120 data fields or so.
• No Help For MLSs With Overlapping Market Disorder or Those Who Want to Data Share.  In response to my question as to whether RPR would be helping MLSs resolve overlapping market disorder in their area by serving as a data exchange/repository, Marty said no, that wasn’t in the plan either.  Of course, users can come to the RPR interface and see data from participating MLSs but there isn’t a plan for an API (RETS or otherwise) to allow MLSs to retrieve aggregate data even if the MLSs in the area agree to such an exchange.
• No Authoritative Record.  In response to my question as to whether RPR will be establishing an authoritative record from the various sources of data (public records, MLS, loans, etc.), Marty said no.  RPR will present the various sources of data side by side but they won’t try to reconcile them.  I think this fact makes their claim of being a “property-centric” system a bit off target.  My understanding of property-centric systems is that they do, in fact, establish an authoritative record from the many sources — they combine the best data to provide a long-term repository of property information, instead of just displaying disparate data side-by-side.  The scenario I posed was as follows:
  • Agent Smith creates a new listing on January 1 and auto-pops the listing from the RPR tax record, and then corrects the square footage, which is off by a significant amount.
  • Agent Smith’s listing expires March 30.
  • Agent Jones lists the same property on April 1 and again auto-populates the listing from the tax record.  Agent Jones will again have to correct the square footage coming from the RPR public records because there isn’t a base or authoritative record available from RPR.
• Application Programming Interfaces (APIs) — (Note: An API is a way two systems (such as RPR and the MLS or a broker back-office system) can talk to each other.)
  • Marty said there will be an API for the public records and MLSs will be able to pull the public records into their own system.  MLS systems also will be able to link to the PDF market and listing reports (though they won’t be available in HTML, just PDF).
  • RPR hopes MLSs will help RPR with authentication by using single sign-on (SSO) standards, though they’ll adapt to whatever the MLS will provide.
  • There will not be an API for any of the third-party licensed data (including listings), just the public records.  If you want to see the other data, you must login to RPR.
  • API documentation should become available in the next 30 days or so.

There were questions from other vendors as well about the APIs and the business model, but the above were the highlights for me.  I walked away from the meeting thinking they were missing a lot of the potential for how a system like RPR could help MLSs and their broker and agent members.  Helping MLSs improve data quality, data standards, and data sharing are all key benefits not being addressed by RPR. Hopefully this will change over the coming months as MLSs negotiate licenses with RPR and require that these issues be part of the deal.

——————————————————————–

Related and recent posts RPR by others:

Brian Larson — Report of RPRs Birth Is An Exaggeration

Rob Hahn — No More Drama and Hype: Known Facts on RPR

——————————————————————–

P.S.  Can I please request that all NAR conventions from here on out be in San Diego?  What a perfect location, with a great convention center, great hotels nearby, awesome restaurants, entertainment, and, of course, the views and weather!

Here are some tips from Adam Bosworth (who worked on ODBC, XML, etc.) on how to build a successful standard:

1.  Keep the standard as simple and stupid as possible.

2.  The data being exchanged should be human readable and easy to understand.

3.  Standards work best when they are focused.

4.  Standards should have precise encodings.

5.  Always have real implementations that are actually being used as part of design of any standard.

6.  Put in hysteresis for the unexpected.

7.  Make the spec itself free, public on the web, and include lots of simple examples on the web site.

To all those involved in trying to create RETS data (not transport) standards, how many of these have we followed?

(h/t Joel Spolsky)

Here’s an email I received today from a member of the Board of one of our MLS customers:

Hi Michael,

I believe you are involved with the Data Standards group at NAR, right? We are still struggling with some definitions and wondering if there is anything published by the data standards group on things that have already been agreed on at the NAR level. Do you have anything like that? Yesterday we struggled with “Single Family Detached” home for over an hour. Is there some help out there?

Thanks, and look forward to seeing you in San Diego.

I typically discuss data standards in relation to MLSs wanting to share data or regionalize, but this is a good example of an MLS simply wanting an easier way to get the data right. I pointed this customer to the RETS schema, but also had to say that it wasn’t user-friendly and didn’t say anything very specific about her question.

From my perspective, a broker asking for a definitive data definition to be published at the national level isn’t too much to ask. I would really like to be able to respond, Yes!, here’s a link to the data dictionary we’ve been working on for the last many years and the definition you’re looking for is on row 28 (or whatever). Wouldn’t that be great? Let’s make it happen.

In my last post, I mentioned that RETS data standards may get a boost from the COVE Group of MLSs starting to work together on further defining standard field names for their MLSs. Standard names have existed for a long time in RETS but they are rarely well populated. This new effort is to reinvigorate standard names and try to figure out how they can be changed so they are actually put into use.

Because there are other regional data standardization efforts across the country, I suggested in my last post that sharing the process for this work with the broader community would be helpful so that the work can be coordinated with work other groups are doing. One of the most basic first steps is defining a format for publishing the agreed upon fields. Spreadsheets tend to be the easiest way for the broadest group of people to access the results, and so they are most commonly used in data standardization efforts.

One of the challenges with spreadsheets, though, is that they are two dimensional and the listing data often is nested, especially when it comes to fields with a list of values. How do you best show the field name and the list of values? One approach is to combine them into one sheet and another is to include the list of values on a separate sheet as shown in the example below (though I couldn’t figure out how to link the two sheets together in Google documents).

Another question is whether to include the data type in this initial effort. In the past, defining data type has created a lot of consternation where, for example, some MLSs use a list of values for number of bedrooms while most others use a numeric value. If this effort is to have meaning and usefulness long term, I think we have to define data types as well as names. Lastly, even though RETS schema doesn’t define fields by property type, I suggest the spreadsheet contain a property type column to define those fields particular to certain property types.

I think using Google Documents or some other web based spreadsheet would make sharing and publishing the information on sites like RETS.org much easier for everyone. Sharing is critical for getting input and feedback, and building consensus around the results. For example, if you think of a better idea for how to format the spreadsheet, you actually can edit the spreadsheet above and the changes will be saved. That’s pretty cool. Google Spreadsheets also can grant only specific people permission for editing.

So, does this approach work for groups to create and share standard fields in an effort to come up with widely adopted standard fields? One of the core objectives is to get as many fields commonly searchable across all MLSs as possible. Is that 50 fields? 100? More? If there aren’t many current fields, will MLSs be willing to change their current fields to adopt to new standards? Lots of questions here but I know there are many MLSs grappling with these exact problems right now and so this is the time to put keyboard to spreadsheet and define as many standard fields as possible.