Jump to content


Photo

OpenTable


  • Please log in to reply
72 replies to this topic

#61 Chambolle

Chambolle

    Advanced Member

  • Members
  • PipPipPip
  • 2,711 posts

Posted 27 August 2019 - 01:48 PM

When someone cites "cloud" and "machine learning" and "infinitely scalable" in the contest of the task of taking reservations I have to think he's full of it. The entire task for all restaurants in the US can be easily handled by a single server.

Also I think there are now 25 restaurant reservation systems with significant footprint in Japan alone (and more over east asia, urp, etc.). Instead of trying to cover every need and suggesting assholistic concepts like demand based pricing, many cater to very specific needs, and have started convincing even traditional restaurants to come on board as they offer them the ability to manage availability on an individual basis and replace their well guarded paper books, offering assurances the data won't leak.


I’m looking at the app and seeing Winnipeg restaurants correctly listed as in Manitoba. If this is one individual restaurant maybe they completed their info wrong for some bizarre reason. Per Orik’s 2018 comment above, I think it’s more likely listings are based on submissions from the clients than AI web crawling millions of data records to figure out where places are.


I honestly have no idea what you are talking about re "AI web crawling millons of data records" ... I'm surely not talking about that and didn't mention anything close to that. I also have no idea of how Orik's above comment (if I'm referring to the correct comment) is at all relevant to what we are talking about. In advance I'll say whether or not a single server can handle the processing, it is immaterial to the discussion. We are talking about what code is or is not doing, independent of load.

I do agree with Orik's first sentence above but it's incomplete ... he needs to add "AI web crawling" to the list ... web crawling isn't AI and it's nothing remotely close to it ... web crawling is pretty simple stuff ... also note that people working on AI don't refer to it as AI among themselves ... it's just algorithms ... a whole bunch of algorithms ... cranking away on lots of data ... the more servers the better
 

4. It could be related to something as simple as an A vs M data error with province information in one of their data sources for a single resto. For example, there is INCORRECT province info (ie Alberta, instead of Manitoba) associated with a Winnipeg Red Lobster located at 1540 Portage Ave, even though the postal code is clearly a Manitoba postal code


Wilf, the bizarre reason (what I generically called a data error*) is, at its origin, most likely ie most assuredly what we in the business call a TYPO ... or indeed someone who doesn't know their provinces ... but that's a TYPO in my book.

*In fact, I started out by typing “typo” … but before I got to the “o” another thought popped into my head and I realized that some nabob may nag me about its technical inaccuracy so I expanded it to “typo / data error” … I continued with “with province information …” and then I made a mid-sentence simplification for the sake of brevity and just got rid of the “typo / ”. This is fact. This is the truth. I have a keystroke log to prove it and I just looked at it and confirmed that this entire paragraph is keystroke for keystroke accurate ** !

** That last sentence (and ONLY that last sentence) was added to show you what bullshit really looks like

Let's continue now ... “data sources” can be indeed by a user typing (and making errors as you have correctly noted) but it can also be from other electronic sources (and those other electronic sources’ sources can be other electronic sources and on and on … each of which may or may not have manual user entries … any and all of these could have poor (ie no) error-correcting … which is inexcusable … but it is semi-shocking to me so see province / postal code mismatches (or state / zip) on public-facing apps from leading vendors in this day and age.

I will note that when sweet little Chambo was an undergrad and was as busy as a Beaver and paying his way thru university thru lots of hard work (and plenty of play), he personally built and oversaw people building such systems that would automatically do this super simplistic stuff ie state / zip correction … and this is back in the Stone Age of Computing, okay. Trust me, this should NOT be happening today anywhere at anytime. This should not have been happening 10 or 15 or 20 years ago. And this wasn’t happening on Chambo’s ship on Chambo’s watch even further back in time than that.


Pras, my dear, how are you ?

Now that I see your screen shots and see exactly what you are referring to, I am confident to say that my above post was dead-on, on point and word-for-word accurate

Per point 3 above, when I say it “occurs with both the iPhone app and the website”, I am referring to the incorrect province being displayed for the Winnipeg Red Lobster. If you haven't yet, search for it and then click on it. Note that even though that AB address is displayed within a box with Google’s map just above on the website, I do NOT believe that incorrect address is from Google ! It’s from elsewhere ... Based upon my limited exploring, Google has it right across multiple of their services ... just do a Google search for "red lobster winnipeg" and notice the MB. TripAdvisor is good too ... blah blah blah

Based upon your app vs website screenshots, I will now SPECULATE … because only the developer ie the coder really know what’s going on ... (but a crafty tester / user could triangulate pretty well if motivated enough ... but Chambo's has minimal interest (for Chambo ... I understand that others may think I'm "invested" here ... but I'm not ... I'm way too busy with other stuff)

I now think that there’s a very good chance that the app and website are indeed “leveraging the same back-end infrastructure” and it’s how the app user interface developer incorrectly opts to access / process location lists when the developer is not expecting a city to have more than one province in the underlying data (maybe because the data was SUPPOSEDLY already massaged and cleaned up … but it's the app UI developer who foolishly opted to make that assumption to blindly trust the underlying data, relying on others to do their job correctly, and thereby putting his end users are great risk and confusion ... and it's app UI developer who is the last line of defense to hide / cover up correctable internal data problems ... they are at fault IMHO ). Obviously I have ZERO idea how they are being fed (ie asking for) this data, but I’ll note that AB is alphabetically before MB … and in total darkness, I'll make a wild guess and say that MAY be highly relevant … or not ... they're other possibilities rolling around in my mind

Note that the website developer dealt with the faulty data situation admirably.

Hence if Chambo were in charge, he'd be calling the app UI developer, along with the testing group, into his office immediately. Somebody may very well be looking for a new job ... if reasonable responses to my questions were not forthcoming ... we don't eff around with nor put our global client base in jeopardy at Chambo Global Services ...



#62 Orik

Orik

    Advanced Member

  • Technocrat
  • PipPipPip
  • 22,102 posts

Posted 27 August 2019 - 01:55 PM

So you're saying the difference is Edmonton, basically? 


sandwiches that are large and filling and do not contain tuna or prawns

#63 Chambolle

Chambolle

    Advanced Member

  • Members
  • PipPipPip
  • 2,711 posts

Posted 27 August 2019 - 02:23 PM

So you're saying the difference is Edmonton, basically?

 
Well ... let's put it this way ... if my hypothesis is correct and it very well may NOT be*   ...then if the MB TYPO was for the Yukon or the Northwest Territories instead of AB, the nobody woulda seen nuttin, MB would have popped up, Pras would be as happy as an almeja and Chambo would have saved himself the Chambosplaining ... but that's not the way the cookie crumbled
 

* but it's very testable by attempting to introduce other post-MB data errors ... like SK YT PE** instead of AB ... and that's where the motivated, crafty tester / user comes in ... how do you add more faulty data ? ... that's the task at hand and it's for someone else to pursue
 
** and no, that wasn't a misspelling of SKYPE ... as Pras will tell ya, those are 3 other Canadian provinces



#64 Wilfrid

Wilfrid

    Advanced Member

  • Admin
  • PipPipPip
  • 86,526 posts

Posted 27 August 2019 - 05:59 PM

Short-hand. Crawl the web, apply algorithms to the data collected.

 

"...they would both be leveraging the same back-end infrastructure of APIs / data sources / data massaging algorithms."

 

I was suggesting that this probably isn't the way that a site like Open Table identifies location and other data for restaurants. It's more likely, as you say, a typo. Agreeing with Orik that there's not much need for sophistication and scale.

 

Do you think Open Table has "users" collecting and/or transcribing this kind of data?  Surely the restaurants just submit it. 

 

And believe me, people working in AI say "AI" all the time.  
 



#65 Orik

Orik

    Advanced Member

  • Technocrat
  • PipPipPip
  • 22,102 posts

Posted 27 August 2019 - 07:06 PM

Pirates too.

 

The way what used to be called Factual (and maybe still is) does locations is a combination of reliable directory services (e.g. Visa vendor lists) with user created venues that are assigned a score based on how often they're selected / checked into, etc. So a not very popular venue could end up having multiple locations but eventually one would win out and Factual would then merge them.


sandwiches that are large and filling and do not contain tuna or prawns

#66 Orik

Orik

    Advanced Member

  • Technocrat
  • PipPipPip
  • 22,102 posts

Posted 27 August 2019 - 07:08 PM

And the problem with crawling the web for this stuff is of course that people are idiots and often get their own business locations, timezone, etc. wrong.


sandwiches that are large and filling and do not contain tuna or prawns

#67 Sneakeater

Sneakeater

    Advanced Member

  • Members
  • PipPipPip
  • 64,519 posts

Posted 27 August 2019 - 07:15 PM

Pirates too.

 

The way what used to be called Factual (and maybe still is) does locations is a combination of reliable directory services (e.g. Visa vendor lists) with user created venues that are assigned a score based on how often they're selected / checked into, etc. So a not very popular venue could end up having multiple locations but eventually one would win out and Factual would then merge them.

 

This reminds me of Chief Justice Renquist's response to his coming in third in a poll asking, "Who is the Chief Justice of the United States?"

 

"That's what's great about this country," he said.  "Everybody's entitled to his opinion."

 

(Of course, this was funny because it was back in the day when there was still such a thing as facts.)


Bar Loser

MF Old

#68 Wilfrid

Wilfrid

    Advanced Member

  • Admin
  • PipPipPip
  • 86,526 posts

Posted 27 August 2019 - 08:36 PM

Factual are still around.  I wrote about them last Thursday.



#69 Wilfrid

Wilfrid

    Advanced Member

  • Admin
  • PipPipPip
  • 86,526 posts

Posted 27 August 2019 - 11:21 PM

And the problem with crawling the web for this stuff is of course that people are idiots and often get their own business locations, timezone, etc. wrong.


Which of course is why whole companies are based on solutions for (semi-)automated cleaning, de-duping, and verifying of large data samples. You could go about compiling restaurant lists that way, but if you’re a subscription service there are cheaper options.

#70 Chambolle

Chambolle

    Advanced Member

  • Members
  • PipPipPip
  • 2,711 posts

Posted 31 August 2019 - 07:43 AM

And Pras, certain people (singular) are creating confusion around here by tossing out terms that they don't really understand at anything other than a super superficial level and having ZERO hands-on knowledge about this stuff but quite frankly my MAIN concern is that YOU fully, completely understand why you encountered your provincial problem and what I was saying 
 
Do you ? 
 
Because don't be shy if ANYTHING that was aimed at you isn't TOTALLY clear ... the most important thing to do when trying to learn new things is to know what you know, know what you don't know and then ask people who know to better explain the things you might be confused about until you finally, completely get it ... and it's perfectly fine if it takes a second or a third or a fourth time ... don't give up, don't be embarrassed, don't worry what others may be thinking about your "silly" questions*, pursue it until the light bulb goes on ... this is the simple, secret sauce to success that so many students seem to let slip by [/Chambosplaining]... Chambo at your service ...
 
* because the reality is that if you are confused then there is a very reasonable chance that others are too ... but they won't admit it, of course ... at least not in front of others

I do fully appreciate that the below paragraph might be challenging to TOTALLY comprehend if one doesn't have some hands-on experience in such systems ... Chambo knew this in advance. Chambo, as usual, was talking to multiple student audiences simultaneously, and this paragraph was indeed aimed at the graduate-level guys ... 
 

I now think that there’s a very good chance that the app and website are indeed “leveraging the same back-end infrastructure” and it’s how the app user interface developer incorrectly opts to access / process location lists when the developer is not expecting a city to have more than one province in the underlying data (maybe because the data was SUPPOSEDLY already massaged and cleaned up … but it's the app UI developer who foolishly opted to make that assumption to blindly trust the underlying data, relying on others to do their job correctly, and thereby putting his end users are great risk and confusion ... and it's app UI developer who is the last line of defense to hide / cover up correctable internal data problems ... they are at fault IMHO ). Obviously I have ZERO idea how they are being fed (ie asking for) this data, but I’ll note that AB is alphabetically before MB … and in total darkness, I'll make a wild guess and say that MAY be highly relevant … or not ... they're other possibilities rolling around in my mind



#71 Chambolle

Chambolle

    Advanced Member

  • Members
  • PipPipPip
  • 2,711 posts

Posted 31 August 2019 - 07:58 AM

That’s hilarious. Does anyone say “”SaaS” any more?

But seriously, is Open Table on prem? I assumed if it ever was, it had moved to the cloud (as we call it).

 

I'm confused ... what's hilarious ? 



#72 prasantrin

prasantrin

    Advanced Member

  • Members
  • PipPipPip
  • 7,390 posts

Posted 02 September 2019 - 03:27 AM

Dear Chambo, I will admit that some of your explanation went over my head (not too hard since I'm pretty short). In layman's terms, someone somewhere effed up, the app developer saw the effed up info and assumed it was correct (or used it without checking if it was correct), and there you have it? I'm open to corrections!

I've decided to blame the eff up on Saskatchewan, since in my research, I found a newspaper in Regina which listed a government office in Winnipeg as being in Alberta. There are many other examples online (including in the address of a legal firm - I likely will never use their services), but Saskatchewanites have always been jealous of Manitobans, so it must be their fault.

Even Edmonton is nicer than Winnipeg, but Winnipeg has better food.

(Btw, YT is a territory. It's a little different or a lot different, depending on your pov.)

#73 Wilfrid

Wilfrid

    Advanced Member

  • Admin
  • PipPipPip
  • 86,526 posts

Posted 05 November 2019 - 11:34 PM

I just noticed I joined Open Table in 2004. Must have some points...