Best practices for data management in prolog

Question

I'm just getting involved in using Prolog to handle more than just the simplest forms of data (facts) and am looking for some guidance from the seasoned Prologers...

If I want to dynamically manage data or facts, I have a couple of major choices, such as do I:

• Manage the data as assertions in Prolog, OR
• Interface to a database from Prolog, OR
• Possibly a combination of both

If I manage facts as assertions in Prolog, I also have the question of the best way to represent those facts. Let's suppose I have a person who has a first name, last name, and an age. I can assert it as:

person(first_name(_), last_name(_), age(_)).

Or have an implicit assumption of what the attributes of person are:

person(_, _, _).  % first name, last name, age

If I want to associate a person with something else, I really need a key for a person. So I might be inclined to assert a person as:

person(id(_), ...).  % Maintain id as a uniq person key; or done implicitly as above

Of course, now I'm making my Prolog assertions look like relational database table entries. And it makes me wonder if I'm taking the wrong approach and overly complicating the representation of facts.

So really, my question is: Are there some best practices to consider when managing medium to complex data in Prolog? The naming convention is the small side of it. I've read bits like the assert/retract in Prolog are inefficient. So I'm also wondering about how to approach the data organization itself, like when to resort to an external SQL database versus Prolog-only representation.

ADDENDUM

I would assume that use of a key for records, as is done in a relational database, would be desirable for the very reasons a relational database uses them. Which means that the key must be maintained. It seems cumbersome to do this manually (explicitly) in Prolog for each case, so how is this done generally? Or is my assumption in correct?

Answer 1

Prolog is based on a relational data model.

Then a relational data model is - banally - adequate to Prolog, albeit - personally - I miss the metadata facilities you get with SQL DML. Documentation - when available - can easily go out of sync, and it's a pain to handle relations with many columns, partly because Prolog is typeless, and partly because you cannot (easily) 'call by name' columns - Prolog misses the 'projection operator' available in relational algebra (and SQL, of course). SWI-Prolog has library(record) to overcome the problem, but I don't like it too much.

Generally, when it come to some 'real world' data modelling, like deeply nested (XML/HTML/SVG/whatever) representations, or dimensionally indexed entities, like spatial and geographical DBs, or large graphs, as those requested by today ontologies, relational only data modelling can be inadequate.

You must supply the missing details, and this technically can be very complex. If you need some indexing your Prolog engine doesn't provide, you will get buried in writing difficult interfaces in low level languages (usually C). Then why not to use some easier language, with ready to use (and debugged) libraries modeled on that complex data ? There are plenty of them.

As a consequence, SWI-Prolog, which development get driven by practicality, instead of abstract language (both natural and synthetic) research that was the initial focus of Prolog applications, has specialized interfaces - for instance - for the Web and for ontologies. See the packages page, most of them are well crafted interfaces to complex data.

From a SW engineering perspective, availability of such interfaces make a difference in language choice. Just to underline how high SWI-Prolog is going in reputation, it has been recently nominated (like Python) for Dutch ICT innovation award.

Ongoing development - like quasi quotation for embedding javascript in DCG based HTML generation - and great support from the SWI-Prolog mailing list are great value adder!

Personally, I'm dedicating my efforts to learn - by applying to practical tasks - RDF modeling.