"Liar! LIAR! LI-A-A-AR!" says Valerie to Miracle Max. I apologize for the Princess Bride reference, but that shrill phrase is often what I hear whenever I use RESO standards and Upstream in the same sentence. It's understandable… there is always a tension between Theory and Practice.
To explain this relationship by way of practice, Theory is abstracted Practice, and Practice is applied Theory. Unfortunately, those who specialize in practice often claim that theorists are detached from the ‘real world,’ and those who specialize in theory often claim practitioners have no fundamental understanding of what they do.
The Upstream/RPR team is the best hybrid. One that embodies the abstraction/application process. We hope to be a conduit, bridging the two worlds. RESO standards have long been an established fact in our industry. They offer the most efficient path to publishing listings for product integrations, and the compliance deadlines that the industry has given itself have been almost universally met.
However, a project like Upstream both leverages the industry’s broad adoption of RESO standards, as well as pushes the boundaries of how the standard is deployed today towards the many different areas into which it will expand in the future. For that, we need to get into some theory, and explaining core theory to a practitioner is no less an art form than combining the essences of practice to those who theorize. Building this bridge is an act of creation… of building.
There have been many questions, even accusations, regarding Upstream's adherence to RESO standards. As we approach the RESO 2016 Fall Conference, now seems a good time to address these concerns “head on.”
NOTE: Now for my second apology… the remaining content "gets in the weeds" a little. I'll do my best to keep it entertaining.
Questions about Upstream and RESO standards can be grouped into four topic areas: standard names, RETS layout, business rules and the Web API. In all cases, the Upstream team has a strong, contributing relationship with RESO and we embrace standards whether they are real estate, programming, or other. Our accelerated use cases (practice) sometimes push the edges of the standards as they are currently defined. Our commitment was, and remains, to adapt with feedback and contribute those learnings in the hope to contribute what we learn and help to expand the standard. Now, get out your machete… we're going into the weeds.
All listing input, listing data storage, and listing delivery in Upstream is natively implemented using RESO standard names from the Data Dictionary. Upstream and RPR implemented its initial database schema and API endpoints (including collections and field names) initially using RESO Data Dictionary 1.4 and later updated to match version 1.5 in the fall of 2016.
Our pilot only extends to five MLSs, which include fields that are not currently the Data Dictionary. In those cases, we use a naming convention and schema that can be changed as the Dictionary evolves. Additionally, Upstream is parcel-centric vs. listing-centric. Updating listings from a parcel-centric database introduces new dimensions to listing characteristics and enumerations from assessment and other sources of property data, and business rules. As we discover and document these nuances, we contribute our findings to accelerate the knowledge base for expanding the Dictionary.
So why are there questions about standard names? Why can't Upstream pass field level compliance? It's a case for… well, case. The RESO Certification requirements state:
"The applicant’s field name MUST identically match the Data Dictionary Standard Name when the definitions match."
RESO standard names leverage XML-world, PascalCasing conventions. My intuition is the original RETS layout lived in an XML world. However, the development community, and RESO, has evolved and adopted the JSON format. It is now the most common data format used for asynchronous browser/server communication. Upstream fully embraces JSON with Google's JSON Style Guide which states names must be camelCased, ASCII strings. Simply put, Iphone becomes iPhone." Same letters, different casing. RESO has fully adopted JSON as a data format. Upstream continued and adopted the JSON naming convention hoping to "skate where the puck is going." Unfortunately, it's not an identical match which translates, on a technical level, to a failure of field level compliance.
The Upstream/RPR team initially proposed a delivery layout that modified the standard RETS format used for listing distribution. We supplemented it with enumerated collections to make it easier for developers to access enumerations (status variants, historical updates, etc.) in a single pass, and that also better expresses the parcel-centric design (and data richness) of the data architecture.
While some developers appreciated the extension, some argued that the classic RETS format is more familiar and universally accepted. Well… that's good feedback, so Upstream will offer a flat, RETS layout as an alternative option, using the RESO Dictionary Platinum format. My intuition is the format will eventually uncover issues once the Web API paradigm shifts from "syndicating" listings to "updating" listings (see Web API). When we get there, we'll cross that bridge together.
Many believe that incorporating the business rules across hundreds of MLSs is simply impossible. And we've discovered that each MLS has hundreds if not thousands of rules. The good news, we've already found patterns. Although the variables change, the thematic rules are often similar. We document every rule we discover and hope to publish anonymous, best practices from around the industry. With that said, RPR and Upstream continue to contribute to the evolution of a business rules standard in the RESO R&D workgroup. We're excited that RESO has created an ecosystem that can distil broad industry input and create a framework for efficiency while allowing local nuances.
As mentioned earlier, the RETS layout and the current Web API definition works well germane to MLS fields and when focused on syndication (distribution). Similar to Upstream's goals, RESO and the Data Dictionary are expanding beyond MLS fields (as evidenced by the Contact standard) and evolving from simple syndication to “Update.” Updating presents interesting challenges not seen in today's distribution paradigm. Let's look at mapping into the MLS vs. mapping from the MLS.
MLSs may have many variants of statuses that get mapped down in a RETS feed for aggregators. For listing distribution, this is easy:
But what happens when starting from listing input using the RESO status like Upstream does, and going the other way? How does the MLS decide?
And then what happens when creating your listing in two MLSs?
Designating a listing in a RESO status alone may not be enough – other attributes will be needed to indicate the intended status in the MLS. Similar challenges must be resolved in enumerations:
Upstream creates the need to go faster down the path towards "Update" that RESO was already heading. We hope that our initiative creates an excellent feedback loop into RESO as we work through these questions with our pilots and subsequent expansion.
Whether it's board participation by various Upstream Board of Managers or workgroup participation by Upstream's partner RPR, we see this as a partnership. So, if you still plan on storming the castle, put the machete down and bring good wine. We have long, interesting conversations about the future ahead of us.
It's been an interesting few weeks between conferences, industry news articles and associated social media commentary. I continue to be fascinated by the passionate opinions and misconceptions around Upstream. I was recently asked for an opinion from one of our beloved news organizations about my take on a potentially competitive offering. As I was writing my response, I was reminded that even after sixteen speaking events in ten weeks, we have a long way to go communicating the mission and benefits of Upstream.
After hitting send, it just made sense to publish my response more broadly aligning to both our theme of transparency and hoping to clarify our mission.
On a tangential note, if the Upstream initiative has become a catalyst that starts cooperative conversations between an MLS and their members or incites industry vendors to develop products that support practitioners (brokers and agents), I will go to bed at night with a smile from ear to ear.
Here is my response…
Thanks for sending me the press release. I'm fascinated by the complement/competitive comparable. It reminds me I still have a long way to educate the industry on Upstream's mission. Upstream's goal is to help brokerages be more efficient and deliberate with their data assets enabling them to be more nimble running their business. Restricting the conversation to listings is myopic. It's a fraction of the data that is core to running a successful brokerage. Efficiency is important and reducing points of entry, and leveraging standards will get us there. But it's not more important than deliberately managing the use of your asset or extending and adopting standards to be more vendor agnostic.
Upstream is more akin to Google Drive than MLS related software. As a document owner, I can share it with you. I can share the entire folder with someone else. As the owner, I can control that access anytime. Google only provides the ecosystem that enables the sharing. They don't touch, manage, police or use your documents. Only the owner and those entitled have access. It's not just for documents just as Upstream isn't simply about listings. The parcel, roster, and vendor data just happen to be where we are starting. Data use agreements are between the broker and the entitled recipient. Any existing agreements between brokers, vendors, and their MLS remain intact. Again, Upstream is closer to Google Drive for real estate data than MLS related software. Brokers determine who gets access, what fields are available and what frequency the data can be pulled.
There're misconceptions about the use cases. We are reducing impact to the practitioners by integrating into the MLS ecosystem. When someone authenticates into their participating MLS, the system will know if the broker is leveraging Upstream. When they access the "Add/Edit" function as an Upstream member, they interact with the Upstream interface. Otherwise, non-members see the standard edit screen. All of the local business rules and data validation are incorporated into Upstream. It's not a "one size fits all" solution. Yes, there will be mobile applications to facilitate access, but our goal has always been to minimize workflow changes. My intuition tells me that the misconception that Upstream is an MLS "alternative" is where comments like "I can't see every broker doing this…" are born. Broker participation is optional. Brokerages can be buy-side only (no listings) and gain from consolidating roster data. You can imagine the future benefit where agent profile data can be unified and shared vs. repeating their profile information on dozens of sites. If a local MLS doesn't participate, the brokers can still leverage Upstream benefits. They won't gain all the efficiencies because listings would be entered twice, but they will access better distribution control and often better data to share. They'd simply turn off distribution from the MLS to the vendors they collaborate with on Upstream.
Finally, I mentioned "better data to share." Many platforms today were built when data and storage were expensive. They have arbitrary limitations such as how many photos can be stored and at what resolution. Upstream doesn't have those limitations enhancing what can be shared to any marketing channel. Additionally, we've added many fields the brokers want such as long photo descriptions. We've listened to the community regarding our API and have added providing data in traditional RETS format. Our original API layout is still available for those that want richer data less accessible in a flat format such as the ability to enumerate through all price changes, etc.
Hopefully, Upstream’s mission is becoming clearer. I welcome your questions.
We seek to create efficiencies by reducing redundant entry, help brokers distribute deliberately by giving them control over who can access their data and inspire innovation by removing artificial barriers when the broker allows.