How Strong and Generic Data Models Ensure Search Accuracy in BASE
On the BitClave Active Search Ecosystem, customers control their identity, decide who has access to their data, and are paid each time businesses use their data to make them offers.
BASE is a platform built around data usage. In this post we discuss the tradeoffs between the two approaches we considered for data modeling and describe the approach we selected for our first implementation.
Data Models
We considered two approaches for data modeling:
- “Strong Typed” data model — where every object has a fixed set of properties
- “Generic Typed” data model — where every object has a collection of <key,value> properties
The “Strong Typed” model is better suited to optimized implementations for very specific cases, while “Generic Type” is more suited to cases where there is a need to cover multiple use cases with a single implementation, even if this implementation is less efficient than the most optimal solution.
In BASE we are building a platform. To facilitate the fastest and the widest adoption of that platform, we want to cover as many use cases as possible, therefore we have decided to go first with a “Generic Typed” data model.
This “Generic Typed” data model will allow us to have a single solution that provides good coverage for a large variety of use cases like car searches, job searches, and service searches (tutor, plumber, electrician, etc….) Later on, BitClave or another 3rd party could optimize searches for a more specific use case.
In the following post we discuss various behaviours in BASE and how these behaviours are impacted by our decision between “Strong Typed” vs “Generic Typed” data model.
Offer Creation By Business
In BASE, businesses create offers based on various properties of the user that is performing the search. For example, a car dealership would offer $100 to a user in the age bracket 20–25, with a salary of $100K+, living in NY.
To implement this offer in a “Strong Typed” model we would have to create a special CarOffer type in design time with the specific properties “Age”, “Salary” and “Location”. To implement this use case with “Generic Type”, we would have a single Offer type with a generic array of <key,value> properties, and we would populate this array in runtime with the keys “Age”, “Salary” and “Location”. We could easily populate this array with different keys for another search.
Search Request By Client
As part of search request, sometimes the user is asked for additional optional personal information to allow for more personalized search results. For example, if a user is searching for a new car, we could ask the user for the details about his current car.
It could be concerning for a user if we asked him for the details of his current car as part of the registration process, but it makes sense to ask for his current car as part of a car-related search request. Once we learn about the user’s current car we can use it in future requests.
BASE needs to store the additional personal information within the Client contract on the blockchain. If we were to implement a “Strong Typed” model for the Client contract we would have to modify the Client contract each time we want to ask for new personal information as part of the search.
Upgradability
All software has to deal with upgrade processes due to introduction of new features or bug fixes. A common technique is to split code and data storage in separate Smart Contracts, so one can upgrade only the code contract, while keeping data contract unchanged, with the assumption that data model remains relatively unmodified.
In BASE we build the platform around data usage, so inherently the data is going to change with time. If we were to go with a “Strong Typed” data model there would be a very high chance we’d have to upgrade our data contract, even we separate it from the code contract.
Search Engine
The search function in BASE plays the role of “matcher”. It proposes a match between Request and Offer Smart Contracts, and then these contracts decide if they want to “make business”.
There will be use cases where use-case-optimized search will be more effective than the general search; this is completely expected and is encouraged. For example, a local search for a plumber might use other sources of information that are not available in BASE, like ratings from some local websites, and this local search would be able to provide more accurate recommendations than a completely generic search.
At this stage of development, we decided to focus on generic searches to cover a wide range of use cases with a single implementation. This would mean just one search — the same search — to cover searches for cars, houses, services and so on.
Introducing BQL Language
Due to the issues mentioned above, we decided to go with the “Generic Typed” data model. To handle searches with the “Generic Typed” data model we also need to define how we are going to handle searches in this type of a model.
Inspired by JQuery, we are working on BASE Query Language. BQL is a language that internally describes the search query in the BASE ecosystem. The initial version supports simple operators like “=”, “>”, “<” on string and numeric fields and will be enhanced to support more complex operators. These include “IN” to check if a value is in a set of expected values, “CONTAINS” to check if a string contains a keyword, “NEAR” to check if a location is within a radius from a given location, the free text search operator “LIKE” to check if a phrase is similar to a given phrase, and more.
With BQL, a query like “user of Age between 20 and 25 with Salary >100k, with location of radius of 10 miles around ZipCode 10036 or ZipCode 94110”, would look like the following:
We are defining BQL to be generic enough to describe various search requests within the BASE ecosystem, so we can develop a generic search engine that takes an input BQL clause and returns matching results.
