Common Schema for Heterogeneous MLS Data Interchange
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing multiple listing services (MLSs) have divergent data structures and formats, leading to inefficiencies in processing and searching property listing information, as they lack a comprehensive common schema for data interchange, particularly when dealing with heterogeneous systems.
Innovation Solution
A system and method for creating a common schema from disparate MLS schemas, allowing for the mapping of individual fields to a unified schema, which combines fields like 'Zip' and 'Zip4' into 'Zip+4', and provides software tools for collaborative schema development and automatic code generation to maintain and extend the schema, enabling real-time updates and data distribution across MLS systems.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a common schema is created to unify disparate MLS data structures, then data interchange capability and search comprehensiveness are improved, but schema complexity and system integration difficulty increase
Solution Approach 1:
The patent introduces a common schema as an intermediary layer between disparate MLS systems and external consumers. This schema acts as a mediator that translates diverse local field definitions into a unified structure, enabling data exchange without requiring changes to the original MLS systems. The common schema includes standardized fields (e.g., property address, price, bedrooms) that serve as universal translators across different MLS platforms.
Solution Approach 2:
The patent segments the data mapping process into distinct components: source MLS-specific fields, common schema fields, and mapping relationships. This segmentation allows the system to handle complexity by breaking down the transformation process into manageable pieces, where each MLS can be mapped to the common schema independently through defined field correspondences and transformation rules.
2Loss of information
If field mappings are created to accommodate all MLS-specific fields, then information completeness is improved, but processing time and system complexity increase
Solution Approach 1:
The patent applies partial action by mapping only the necessary fields from each MLS to the common schema rather than attempting to map every possible field. The system identifies and maps essential fields (e.g., property details, pricing, location) while optionally handling MLS-specific fields through extensions or annotations. This selective mapping approach maintains information completeness for critical data while reducing processing overhead.
Solution Approach 2:
The patent implements preliminary action by pre-defining the common schema structure and mapping relationships before actual data processing occurs. The schema and its field correspondences are established in advance, allowing incoming data from various MLS systems to be automatically transformed without real-time analysis. This pre-prepared mapping framework significantly reduces processing time during data ingestion.
3Reliability
If separate database retrieval is used for each MLS, then data accuracy is maintained, but system complexity and operational inefficiency increase
Solution Approach 1:
The patent merges multiple MLS data sources into a single unified data structure using the common schema. Instead of maintaining separate database retrievals for each MLS, the system consolidates all MLS-specific fields into the standardized common schema format. This merging approach preserves data accuracy by maintaining original field values while enabling efficient processing through a single unified structure, eliminating the need for separate retrieval operations.
4Adaptability or versatility
If comprehensive field mapping is implemented, then search capability is improved, but device complexity and maintenance difficulty increase
Solution Approach 1:
The patent incorporates feedback mechanisms that allow the mapping system to automatically adapt to changes in MLS data structures. When MLS field definitions are updated or new fields are added, the system can receive feedback about these changes and update the mapping relationships accordingly. This feedback loop maintains comprehensive search capability while simplifying maintenance by enabling automatic adaptation rather than requiring manual reconfiguration of mappings.
Data Source
AI summary
Systems and methods for developing a data repository containing property listing information automatically acquired from a plurality of multiple listing services (MLSs). The property listing information from various MLSs can be mapped to a common representation and stored in the data repository. The invention utilizes and transforms information from different source MLSs which may have a particular data schema that may or may not match a predetermined common schema for the data repository. The listing information is thus consolidated from MLSs even when their schema may be different from each another or the predetermined data repository schema. The data repository schema may be selected such that each of the fields that comprise the source MLS property listing information in its native schema (and all its elements including but not limited to, agent rosters, office rosters, and tax data) can be mapped from the source schema to the data repository schema (the destination). Accordingly, the data of the source property listing from various MLSs can be preserved. Possible mappings include one-to-one, one-to-many, many-to-one and others. For certain applications of the invention, mappings may be direct where the listing information data from an MLS is simply copied as is, or it can undergo a data transformation process that is based on a predetermined set of listing field mapping rules.