The naming trick makes clear what each position means: The order of arguments follows that of the name's components. So, if the name contains id_user_text, then the arguments are also in this order: ID of comment, ID of user, and the text. This is a simple mnemonic technique I use for naming important predicates.
As to your first question, we are now talking about (database) integrity constraints. So I would first state which rights are admissible at all by clearly defining what we consider a right. For example, in this concrete case:
right(delete).
right(hide).
right(modify).
Next, I
describe the situation that an admin was inadvertently assigned a "bad" (i.e., not actually existing) right:
user_bad_right(ID, R) :-
admin_id_rights(ID, Rs),
member(R, Rs),
\+ right(R).
Now, I can ask Prolog:
Are there any bad rights assigned? I do this by simply posting the most general query about this relation:
?- user_bad_right(ID, R).
false.
I conclude:
No, there are no bad rights assigned.
As for creating objects: This is a good case of using the dynamic database, i.e., predicates like assert/1 and assertz/1. The database is very good for frequently retrieving information, but not good for frequently updating the information. This is a fitting situation: Comments are presumably only posted once, and in that case, you can simply add such facts to the database.
But you can of course also make all this explicit, and first construct a term of the form comment_id_user_text_points(3, 1, 'hello!', []), and then reason about such terms (instead of reasoning about the asserted facts). Note that this term looks exactly like the fact syntactically, due to the homoiconic nature of Prolog. Therefore, you have many ways to reason about your data. You can even write all such terms to an external file, and simply consult all facts (and even rules) it contains by invoking consult/1 dynamically.
As to your first question, we are now talking about (database) integrity constraints. So I would first state which rights are admissible at all by clearly defining what we consider a right. For example, in this concrete case:
Next, I describe the situation that an admin was inadvertently assigned a "bad" (i.e., not actually existing) right: Now, I can ask Prolog: Are there any bad rights assigned? I do this by simply posting the most general query about this relation: I conclude: No, there are no bad rights assigned.As for creating objects: This is a good case of using the dynamic database, i.e., predicates like assert/1 and assertz/1. The database is very good for frequently retrieving information, but not good for frequently updating the information. This is a fitting situation: Comments are presumably only posted once, and in that case, you can simply add such facts to the database.
But you can of course also make all this explicit, and first construct a term of the form comment_id_user_text_points(3, 1, 'hello!', []), and then reason about such terms (instead of reasoning about the asserted facts). Note that this term looks exactly like the fact syntactically, due to the homoiconic nature of Prolog. Therefore, you have many ways to reason about your data. You can even write all such terms to an external file, and simply consult all facts (and even rules) it contains by invoking consult/1 dynamically.