[Rets-dev] The MLS Transaction Set
David Harris
dharris at FMLS.com
Sun Aug 5 21:12:20 CDT 2007
Dave,
I share your concern for the value position of the MLS going forward.
Kristen Carr and I are planning on addressing this point specifically in
our presentation on Wednesday. We are recording that presentation and
plan on offering it for download soon after.
In our presentation we make the case that RETS can position itself as
the savior of the MLS, but only if the MLS community embraces it.
David
From: rets-dev-bounces at rets.org [mailto:rets-dev-bounces at rets.org] On
Behalf Of Dave Sullivan
Sent: Sunday, August 05, 2007 5:37 PM
To: Paul Stusiak
Cc: rets-dev at rets.org
Subject: Re: [Rets-dev] The MLS Transaction Set
MLSs originated in a time when there was NO information available about
real properties for sale. The MLS book provided REALTORS with a
twice-monthly list of properties for which they could earn a commission
if sold, a brief description of the property and a small B&W photo. For
decades, the MLS was the best source for information on a real property,
as it added photos, then color, then links to video; but the advent of
the Internet is rapidly making this less true.
For the sake of discussion, let's say someone starts a service to
provide comprehensive information, pictures, and video of a property for
REALTORS which they can link to in their listing. This would let them
avoid filling out the entire MLS form and just enter the factual data of
property address, legal description, price, terms, exclusions, etc. The
MLS would no longer carry the property description, but merely a link to
it.
In this environment, what does RETS convey?
=====================================
Regarding the Listings.xsd, the schema propagates existing MLS table
structures that use STATUS to convey several different dimensions of the
business status of the Listing. Is it offered for sale or not? If
offered, has a contract been accepted by the Seller? Is the contract
contingent on anything? Is so, what are the contingencies and when do
they expire? (I notice quite a lack of patience with those MLSs that
try to include all this information in their STATUS field, which then
makes it incompatible with the RETS standard)
======================================
As far as attending meetings goes, that would only be effective if
stakeholders are receptive to a significant change in perspective. In
my experience since 1999, stakeholders represent the business positions
of their employers. There is a natural tension between the client-side
businesses which would like to receive lots of services, and server-side
organizations who must bear the cost of providing them. In this
environment, achieving a standard is a much lower priority than
negotiating the scope of functionality.
Dave
At 03:59 PM 8/5/2007, Paul Stusiak wrote:
Thank you for your comments.
If I understand your comment correctly, I think if you have a look at
the Listings.xsd in this zip file
http://www.rets.org/cms/files/rets2schema_1.zip
that the agency information is front and center. While it is possible
that there are missing elements, and I encourage you to provide
information that you feel is missing to the MLS Schema group through me
by email or by attending a meeting, I think that containers like the
ContractInformation hold some or all of the elements that you are
interested in.
While I think that your definition is a little narrow, you'll see that
the work on the MLS schemas have moved to a containment of other schemas
within the listing schema. This is not the final design, but has had
broad support from those interested in the MLS data and the exchanging
of the data.
The RETS community has found it necessary to do more than rely on
external sources who have traditionally not provided the accuracy or
timeliness demanded by their members, forcing the community to describe
the information. Interchange of this information is a very important
topic for the community and RETS seems the logical place for it. Both
RETS1, through the metadata function and RETS2, though metadata and XML
schema have provided this facility.
Recently, we have not been using the word transaction in the manner that
you are. In general, that has been reserved for describing the workflow
management commonly known in the industry as Transaction Management
Systems.
I do not agree with the tone of your final paragraph. While this may
reflect the situation in your local experience, I have found the MLS
operator community to be strongly in favor of new and innovative
techniques to support their members.
Paul
Dave Sullivan wrote:
All:
The next issue I would like to discuss is the concept of MLS
"transactions".
I submit that there is only one set of transactions that is native to
the MLS - the publication of agency to sell a real property and
subsequent updates to the status of that agency, including sale.
Everything else in the MLS is advertising or publication of information
from other sources.
I believe we could come to agreement on the content of the agency
transaction in a few hours, and we probably should. This transaction
needs to identify the real property, of course, by address, tax ID,
etc.; but it doesn't need to _describe_ it.
With this out of the way, the discussion of the rest of the content of
typical MLSs could properly deal with its role as advertising;
recognizing that brokers and agents must continue to find new and
different ways to sell their inventory and services ... and that perhaps
the MLS cannot keep up with the pace and pressure of the new, electronic
marketplace.
Dave Sullivan
President, ZONAR Corporation
PO Box 3335
Oakton, VA 22124
703-255-3800 ext 712
Cell 703-283-7007
FAX 703-621-9526
http://www.zonar.com <http://www.zonar.com/>
< http://www.zonar.com/ <http://www.zonar.com/> >
------------------------------------------------------------------------
_______________________________________________
Rets-dev mailing list
Rets-dev at rets.org
http://lists.rets.org/mailman/listinfo/rets-dev
--
Paul Stusiak
Falcon Technologies Corp.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rets.org/pipermail/rets-dev/attachments/20070805/d4ff0e9f/attachment.html
More information about the Rets-dev
mailing list