OnBlog: Lifestyle Listings Engine…stuff. PART 1

Lifestyle Listings Engine…stuff. PART 1

This is part one in a multi-part series that will cover what we envision the Lifestyle Listings Engine being capable of, both for-real delivered day one stuff and some sky-pie. In addition to talking about some of the interesting (at least to us ) cognitive science used in creating search and about compelling implementation possibilities, I’ll also spend some time talking about the (mostly) more prosaic, but altogether necessary data practices, systems, etc. that go into making listings data useful in search.

Let’s start with some of our assumptions about search. I tend to distill that larger and more abstract concept into a simple one: that search is a question resulting in an answer. Because most online property search in RE is so flawed, so far afield from what we think of as a question let alone an answer, we’ve lost sight of this simple fact.

Assumptions:

#1) search is a Question that results in an Answer

#2) good search is the Right Question resulting in the Right Answer

#3) great search is the Wrong Question(s) resulting in Right Answer(s), Right Question(s), or both.

We’ll deal with the Answers first, since they are both the destination and the path. Oh yeah…very zen, very deep, I know.

Good Data

One of our primary assertions as a company is that good data is arguably the most necessary component of effective search. So before we could even start talking about building a new search product from the cognitive query side (aka Question), we had to be certain about the constituent data (aka Answer). I’m leaving our community and other content out of the convo because we’re (rightly) already known for it, and focusing on the listings that are both the target and a core component of our Human Centered Search.

“Good data”–I used that term earlier, but I really dislike it since I believe data has to be distilled into at least information or it’s garbage, and I only use “data” at all in this context for reasons of common usage (and SEO ). At one point I posted about the “knowledge hierarchy” (DIKW), and made (I hope) a reasonable argument that Onboard Informatics is a provider of information, knowledge, and wisdom–not data.

Still, you always start with data, and while I don’t necessarily believe that “good data” exists, I’m tear-my-hair-out certain that “bad data” does. In the case of listings, that would be…um…most of it.

Bad Data

So what do I mean by “bad”? Data can be bad in a lot of ways (and mostly is), but for my money the very worst way for data to be bad is through inconsistency. Honestly? Wrong answers are just fine by me, as long as they’re consistently wrong, in terms of both frequency and nature of wrongness. The more consistent the wrongness of the data, the more subject to consistent correction it is.

Our approach treats listings data simply as another content set to be aggregated (admittedly a more generally problematic one), making no real assumptions (at least on the systems side) as to source. Listings data is, as a rule, fairly inconsistent in the ways it’s wrong. Basically, everything that can go wrong with it generally does–from security and access, to file and server locations, to schemas and data structures, to content, to, well…everything.

Even more fun, it tends to go wrong in very creative ways. As with any rule there are exceptions, of course, but you don’t design systems primarily around exceptions. In an open system you design around an awareness of input variation, and create subsystems for handling those variations.

Problem with Listings Feeds

This is where most of the efforts at aggregating listings have failed. They’ve all engaged in one-off, organic system development leading to a lot of very specific solutions, but no generically applicable heuristics. So while this or that listings feed may be robust at inception, the system which supports it is anything but.

So every new feed represents a significant new dev cycle. Even worse, because of the inconsistency I talked about earlier, the already implemented feeds break constantly and require a very individual (i.e. slow, expensive, inconsistent) effort for resolution. And heaven help you if the guy who busted up that particular feed isn’t with you anymore.

To be fair, this is usually the result of pacing development expenditure to a particular business model’s pattern of growth or a marketing roadmap–and I’ll cop to doing it myself. One of the big lures Jon and Marc dangled to get me back into RE was the chance to do this sort of thing the right way, aka the Onboard way.

Great Search

What’s the right way? An expert system, a system which uses a “fuzzy” or heuristic knowledgebase to make decisions in order to implement and maintain data in a robust, repeatable way. I’ll go into that tomorrow, in Part Deux.

- Liam

Save To: