[jeletonskelly]

I used to work at an OTA (online travel agency, ie Booking.com, Hotels.com). There's all kinds of complications to what seems to be a pretty simple thing: a building with rooms that are either occupied or not. There's multiple rates per room for a single night, then there's something called room rate plans which I won't get into. In other words: it's more complicated that we think (or than it needs to be).

[segmondy]

This type of things is based solved with Prolog. The issue is that folks are trying to solve declarative problems using procedural/object oriented/functional programming. Because we store data in databases, we have twisted it into a database problem but it's not.

  book(Room, Rate):-
     availableBuildings(Buildings),
     availableRooms(Buildings, Rooms),
     rate_less_than(Rate, Rooms)
     cheapest(Rooms, Room).

However complex you think this problem is, it's pretty simple. It's a very old problem, scheduling, well understood and solved. Using the wrong tool makes it a nightmare. Using the right tool makes it ridiculously easy. The solution is not the database, but the language.

[mfrager]

Very interesting... my inclination is that you’re probably right. Any tips on how to learn to use Prolog with pulling data from external sources?

[segmondy]

Prolog's DB is just a text file. You can construct a DB file by using SQL to select into a text file.

You can use ODBC http://www.swi-prolog.org/pldoc/doc_for?object=section(%27pa...

You can use CSV http://www.swi-prolog.org/pldoc/man?section=csv

I've used the above methods.

For RDF, you can load with various methods even over http http://www.swi-prolog.org/pldoc/man?section=rdflib

[e12e]

I too would like to hear about getting facts from an sql db, and writing back results from prolog - it's hard to see how a prolog text file can/could be used as a source for transactional problems like booking (making sure the answer you find can be committed while still valid).

I suppose one could have a prolog service that came up with suggestions, ordered by preference, and then attempt committing them in order to the actual transactional storage layer. But I don't see how you could avoid re-implementing transactions.

With an rdms you could look for options, and attempt a booking in a transaction, and have a fairly established way to resolve conflicts.