Data Topics FAQ

RESO has added two new fields to support Delayed Marketing Exempt Listings:

• DelayedMarketingYN – true if marketing of the listing is delayed, false or null otherwise
• DelayedMarketingDate – the date when marketing will begin

These fields will be available starting in Data Dictionary 2.2, but providers may start implementing them now.

More Info on Delayed Marketing Exempt Listings (DMEL)

Data shares are common in the industry, especially among neighboring MLS markets.

Providers that implement data shares should be sure to include the relevant originating and source system information so end users can filter and differentiate between listings in various markets.

Each Data Dictionary resource has the following fields:

• OriginatingSystemID – the unique ID of the system where the record originated
• OriginatingSystemName – the unique name of the system where the record originated, commonly the name of the MLS where the record was entered
• SourceSystemID – the unique ID of the system where the record was obtained from,usually the ID of the system hosting the record
• SourceSystemName – the name of the system hosting the record

  Example
  Assume that there is a data share between MLS A and MLS B. The OriginatingSystemName of records created in A or B could be “MLS A” and “MLS B,” respectively.

OriginatingSystemName is the most commonly used field to indicate which system a record was entered in. End users should be prepared to support this field to differentiate where records originate from, but also OriginatingSystemID in cases where it is used instead.

RESO Alignment Reports Can Help with Implementing Data Shares

With the increased usage of AI in the real estate industry, data providers should ensure that licenses for AI tooling do not violate their data licensing agreements.

RESO is focused on data standards and does not play a role in how data is used. Please consult with your vendors and data providers if you have questions about acceptable use.

More Info on RESO and AI

When working with RESO-certified systems, it’s important to understand that end users will still receive local data elements in their feeds. The Data Dictionary is extensible, meaning that resources and fields can be added, and the majority of enumerations are “open,” meaning that data providers can use local options when the Data Dictionary doesn’t have something defined yet.

Rather than trying to ingest everything in a feed, end users should approach RESO data sources by first identifying Data Dictionary data elements they need for their products and only then examine local resources or fields. If local data is found that is not mapped to its corresponding RESO elements, this is potentially a compliance issue if the provider has been certified recently. Contact dev@reso.org for additional questions.

More Info on Extensibility & Omissibility in the RESO Data Dictionary

Every RESO resource has a ModificationTimestamp field, which is required for certification and should be updated every time a record is created or updated. Some providers have additional fields in order to preserve the modification timestamp in the originating system.

ModificationTimestamp should be used for replication of data.

More Info on ModificationTimestamp

Records can either be marked as deleted, removed from a user’s feed or removed from a system entirely.

Records that are marked as deleted may have a Delete status in the StandardStatus field; however, depending on the type of feed a user has access to, they may not be able to see records with that status.

When records are removed from a feed or a system entirely, end users may not know it has been deleted. Consumers are expected to perform regular audits to ensure that the listings they have replicated locally still exist in the source system.

More Info on StandardStatus

End users should take care to observe the Permission Field in the Media Resource. Not doing so can result in compliance issues with data licenses.

More Info on Permissions