At last week’s semi-annual meeting of RESO (Real Estate Standards Organization, née RETS), I had the opportunity to participate in a panel session titled “RETS Issues, Challenges & Perceptions”; following what I thought was a great session, it seems that there is some continuing mischaracterization of my position (and message) that could use some clarity.

First, it is worthwhile to note that this panel arrived with the backdrop of “the COVE ultimatum” just days prior, in which roughly 20 large MLSes that comprise the “Cooperative Venture” (COVE) Group expressed concern that the standardization of Real Estate data has been inadequately progressive and, to that end, would be assigning its respective subject-matter experts to the task.  Ironically enough, my MLS is a member of the COVE group and, although I had some foreknowledge heading into this panel, that’s about where my involvement ends.

Second, the intent of the panel was to publicly mobilize some aspect of the effort and there was hope that confronting some of our collective shortcomings might help to that end.  I have well-documented my position(s) on this blog and have spoken to a number of the industry stakeholders about these issues, but (as David Harris put it so well) the whispering majority is currently overshadowed by the loud minority.

I’ve already summarized my position on what needs to happen with RESO, but here are my point-by-point criticisms with the Standards that RESO defines:

• RETS needs to be accepted for what it is: a Transactional system.  RETS was not designed for the task of synchronization (i.e., copying portions of the MLS in bulk) and another transport should be developed & advocated soon to address this need in the industry.  There are a seemingly-infinite number of third parties receiving MLS data and their number is only increasing every year… a standard method of copying data in a lightweight manner would benefit every MLS, vendor, and consumer of RE data.  This is especially needed for data-sharing efforts and VOW providers.  RETS is just too fat a protocol (that costs real money to transmit) and requires a number of “guesstimating” approaches to ensure consistency between source & client.
  
• RETS is ugly.
  Of course, no one in that room is going to admit to RETS being ugly… most people there are making their livelihood either supporting or consuming RETS, and many had a hand in its creation. Even David Harris was quick to point out a likely bias in the room.  However, the empirical evidence – well-documented in the RETS forums and especially the ezRETS and libRETS mailing lists – suggests that RETS is a very odd duck in a world of lots of standards.  Although I was chided during the session for saying that “DMQL was basically made up for RETS”, the reality is that RETS’ DMQL has little in common with its likely namesake “Data Mining Query Language” as publicly theorized in the early 90s.  Aside from some syntax similarities, RETS’ DMQL has no methods (as far as I’m aware) for interacting with metadata rules and constructs as part of a query, which was the basis for the “real” DMQL.  Beyond that, RETS uses a “just like HTTP” and a “just like TDS” payload to return “just like CSV” data, which is a lot of work… as Chris McKeever aptly described it in the session, “it’s like we’re building two bridges over the river instead of one” and, to paraphrase, just for the sake of saying that we made two neat, big bridges.  “Other” access methods (i.e., CSV files) shouldn’t be frowned upon just because they are simple – sometimes a simple approach is actually the most elegant.
  
• Data standardization is very important, but also very difficult.
  RETS has (and has had) over 500 defined “Standard Names” fields for over 5 years.  To date, not a single MLS (okay, maybe one, the one who submitted most of the list) has implemented them all.  This is because they include definitions of the data, which are generally not universal… Real Estate is still largely local:  What you call a “patio home” I call a “garden condo”, and what may be to building code in your jurisdiction may not here. My biggest concern is the loss of fidelity that will occur when we standardize.  One of the best examples of this was from another MLS’ aggregation effort, in which they listed commercial building heights in ranges (i.e., “15-20 stories”)… which means that no matter how you form the new universal “Building Height” field, you can’t say “15” or “20” without losing the original value’s meaning.  There are hundreds of examples of this in any MLS that has been around for more than a decade.  While I advocate the continued effort of mapping the universe of Real Estate data, I don’t think that it will come to fruition beyond its existing state any time soon.
  
• Data standardization is somewhat unnecessary.
  This is the one that sets most people off, but is the most important one “on the ground”.  Every market has mostly local Real Estate data consumers – local publications, local website providers, and local franchises and brokers that want/need access.  None of those particularly care about whether the MLS’ data conforms to any standard – they just care that it is easily digestible and readily available.  Data standardization matters most to national and regional efforts:  It is not until you leave a single definition of real estate data that you run into a problem.  For many data consumers, that just doesn’t happen.  For me, making the feeds timely and well-documented satisfies 99% of my data consumers.  They only implement their download system once, by and large, and don’t really need a quintupled implementation cost because Real Estate commands RETS.  It just doesn’t make sense.  It really shouldn’t be easier to set up an eBay store than to display your own listings on your own website, but it is, and I think that’s just wrong.

Hopefully, this helps clear the air and takes some of the biased reporting out of the mix.