Extending Logic Programming with Labelled Variables: Model and Semantics

has been reviewed. The comments of the reviewers are included at the bottom of this letter.

As you can see, at least one reviewer has serious misgiving around the publication of your submission. Nevertheless, we invite you to respond to their criticisms and outline a plan of revisions that we will submit to the reviewers. If the plan is accepted, we will mark the paper as "accepted with major revisions" and give you a deadline for the revised version.

To expedite the process, we ask you to send us your proposal by 21-June-2017 with an email at the usual address

cilc2016specialissue@easychair.org

Once again, thank you for submitting your manuscript and we look forward to receiving your proposal.

Camillo & Alberto

Guest Editors

REVIEW 1

PAPER: 2 TITLE: Extending Logic Programming with Labelled Variables: Model and Semantics AUTHORS: Roberta Calegari, Enrico Denti, Agostino Dovier and Andrea Omicini

Overall evaluation: 1 (accept with minor revision)

Overall evaluation

SUMMARY: The paper extends the framework of logic programming with labelled variables, an interesting notions closely related to Gabbay labelled deductive systems. The resulting languages is expressible enough to accomodate the issues raised by the "today's pervasive systems".

Section 2 well introduce the model, with particular attention to the notion of compatibility of variables and labels. Section 3 introduces the denotational semantics, by means of the one step consequence function, which is proved to be monotone and continuous. Also an operational semantics is given that basically mimics the one of LP. Finally the denotational semantics and the operational semantics are proved to agree. Section 4 explain the implementation and Section 5 illustrates three interesting case studies.

OVERALL EVALUATION The paper does not seem to me too deep, but it is worth anyway to be published as it may have some meaningful application. Actually, I do not understand the focus on "distributed situated intelligence": in my opinion, there is no focus on "distributing at all". Actually one requires here full knowledge and a centralised programme. Something like Concurrent Constaint Programming looks to me far more "distributed".

Another weak point of the paper is the extremely poor presentation. I give some suggestions below, after a small technical issue.

TECHINAL ISSUE

In Page 3, point b, it is stated that the set of labels L is a subset of the powerset of "basic labels" B. Then the authors requires that each label should represented finitely: what does it mean in mathematical terms? Why not simplying assuming that L is contained in the finite powerset of B? On the same line, what does it mean, mathematically, that the function f_C "can argue over this representation"? I think it is important to be completely precise on this side, because it may effect the proof of continuity in Proposition 3.2.

MINOR COMMENTS AND TYPOS Page 2, second paragraph: "removing some limitations": this is Inglish. Write instead "going beyond some limitation"

Predicate symbols are not introduced, while all the other standard notion of Logic programming are. Why?

The operator f_L is required to be associative, commutative and idempotent. Is the empty-set its neutral element?

In Section 2.2, the author explain that "Head" is an atomic formula, without never explain what a formula or a predicate is...

Section 2.2: "the unification of two labelled variables ... /theta is the most general substitution". What is the most general substitution of variables? It does make much sense to me.

Table 1. The row and colums are symmetric: there is no difference between c_1,v_1,... and c_2,v_2,... but then substitution always becomes v_1/v_2. Why? Is one the head of a clause and the other an atom of the goal?

Table 1. What is a functor? The term functor has a clear mathematical meaning. In this setting it has no sense, even if I can understand what the authors mean.

Figure 1 and many other figures: I am not sure whether using figures for examples is a good typographic idea. I guess that examples should have their own proper environment.

Figure 1, line _2: "In particular, f_C(t,l) ..." --> "In particular, in our example, f_C(t,l) ..."

Section 3.1: "We define the function /tilde{f}_L that in a sense ..." which sense??? PLEASE BE FORMAL!!!!

The beginning of Page 7 "Figure 2 reports ... LP-operator" is extremely confusing. what is the standard =/2 LP operator? Are the authors explaining the meaning of =/2 in term of =LP that then you say it is just =/2 ?

Definition 3.1: What is going on in between the third and the fourth item? I do not understand.

Before Corollary 3.3. Again the authors define something in terms of something else that is not defined: uparrow omega is defined in terms of uparrow k, which is not defined (but that it would take one line to say that T_Puparrow 0 = Id and T_Puparrow (n+1) = T_P ; T_Puparrow (n+1) )

Corollary 3.3: "there is a notion of least model". Sure it always exists a notion of anything. Say: "T_P has a least fixed-point" or "T_P has a least model".

Proof of Corollary 3.3: here the author should use either Knaster-Tarski or Kleene, not both of them!

Proof of Proposition 3.4: what are "standard details"?

Page 11: "Solve/3" does not appear in Listing 1. I do not understand what are the authors referring to.

REVIEW 2

PAPER: 2 TITLE: Extending Logic Programming with Labelled Variables: Model and Semantics AUTHORS: Roberta Calegari, Enrico Denti, Agostino Dovier and Andrea Omicini

Overall evaluation: -1 (reject)

Overall evaluation

This paper presents the theoretical model of Labelled Variables in Logic Programming (LVLP).

After an introduction including two illustrative examples (WordNet and interval arithmetics) the Labelled Variables Model is introduced. It is based on the classical logic programming and the Herbrand interpretation. The LP-rules are extended by labelings, variables are assigned such labels and there are two important functions f_C and f_L, whereby f_C: H x L -> {true, false} is a _compatibility_ function to support the acceptability of labels for certain terms and f_L: L x L -> L is a _label_ _combination_ function. Beside the classical LP computation, LVLP allows a second "customizable" (somehow parallel) interpretation based on the labelings. So, labels can be interpreted as some kind of properties, categories, or attributes of terms or values, which are combined using f_L (and f_C) during resolution. Thereby, f_L can be chosen domain specific, it can not only include set operations, like union or intersection of label sets but as well e.g. arithmetic computations. A fix-point semantics and a corresponding operational semantics of LVLP are given and discussed, followed by conclusions and future work.

In general, I like this simple idea of extending logic programming by extending the variables and values by some further attributes and interpretations. However, I fear that the paper is not yet ready for publication in a journal. I miss a deeper discussion of related work, a number of potentially important points are left out (at least they should be discussed), the application area of "distributed" situated intelligence is not really motivated, and, furthermore, there are several issues in representation and layout/typing. Therefore, I opt for "-1 - reject". I will go into detail wrt. the points of criticism in the following.

Concerning related work, just one short and very general sentence "Most other works ... focus on specific scenarios ..." is given. A deeper discussion of related work is left out. Moreover, I think, that the difference of the presented approach and the mentioned other papers (last paragraph, Section 1) is not primarily that these later are "scenario specific" while LVLP is "general purpose". Some of the other approaches are as well "general purpose", but their semantics is different. Also, since the labels can be seen as some kind of category or attribute, it could make sense to check, whether there are approaches in object-oriented logic programming which could be related. Furthermore, a label could also be interpreted as a type. Types in logic programming could, thus, be some issue of related work. A similar approach, we find in functional programming by dependent types, it could be also interesting to discuss the relation of LVLP to that.

I missed an argument, why LVLP should support _distributed_ situated programming. How do you deal with distributed (potentially conflicting) computations? What about common variables in distributed systems, distributed backtracking etc.?

Further issues and point for discussion:

Section 2: "labels provide a customizable computational model ... possibly not declarative"

If it is _not_ declarative, then this would evoke serious problems concerning semantics. You would e.g. have to deal with the problem of combining declarative (timeless) and imperative (time dependent) computations. (How) Is this covered in your semantics?

Section 2: Example programs. Please use a larger font.

Section 2: "a recipe with 200 (+/-20) calories" yields a result with "166 calories"?

Section 2: The example computations using intervals and e.g. the computation of sums

of calories presupposes the existence of some (interval) arithmetics solution mechanism and concerning functions. I expect this is then realized in f_L, but it should at least be mentioned here, otherwise the computations seem somehow "magic" at this point.

Section 3: "most general substitution" -> "most general unifier"?

Section 3, Table 1: I would prefer to see the complete result triples.

Section 3, Table 1: Why is the result of unification of two compound terms s_1 and s_2

just true or false? Shouldn't there happen label combinations? Please explain.

Section 3.3: "f_C (t,l) = ... at least an element ..." -> "at least one element"?

Section 3.3, Example 1 is not really an example, but a merge of an explanation or

motivation of f_C. An actual example would be helpful here, by the way.

Section 3.3: "Summing up ... can be written as: (true/false / f_C (theta,A), theta, A)"

Maybe better "... ( (true/false) / f_C (theta,A), theta, A)"? Suggestion: Parenthesis for "true/false", because "false / something = false".

Section 4, Text between Example 2 and Example 3: Here you suggest, that CLP(X) can only

compute with numbers or even integer intervals. But this ist not true. The "X" in CLP(X) stands for a domain LP is extended by. You can, of course, choose for "X" other domains and solvers. The solvers, by the way, are also also necessary for your approach (to be used by f_L).

Section 4, Example 3: I'm not sure, but shouldn't the 4 wordnet_fact clauses also

be part of I_1? If not, please explain.

Section 4 and Conclusion: "Future work will be devoted to a more complete proof of

the result sketched in Subsection 4.1." Is this proof then safe in its current version?

Conclusion and Motivation: "distributed LP". See the question above:

Why should LVLP support _distributed_ LP? What about distributed common variables and their bindings, distributed backtracking and the like?

We are pleased to inform you that the reviewers have recommended publication of the revised version of your paper. Please, send us an archive file containing both latex sources and the pdf of the final version, using the email address cilc2016specialissue@easychair.org

The deadline is 24th November, 2017

Once again, thank you for submitting your manuscript. Camillo & Alberto Guest Editors ======================================================================

REVIEW 1 **

I think that the paper is now ready for publication.

The authors have implemented all the suggestions in the plans that they submitted few months ago.

In particular, I am glad to properly understand now the meaning of "distributed situated intelligence".

The again revised version (2017-09-05) now covers most of the raised issues and suggestions. The most important issues - from my point of view - were (a) a more detailed discussion of related work (now to find in Section 6) and (b) an explanation of the "support of distributed situated intelligence" (now Section 2.4).

So, I would rate the paper now as "weak accept" (if this were possible). Nevertheless, I'd like to point out, that the example codes and the Figures 1 and 2 are still very much too small to read! .

Dear Andrea,

your paper

Extending Logic Programming with Labelled Variables: Model and Semantics

has been reviewed. The comments of the reviewers are included at the bottom of this letter.

As you can see, at least one reviewer has serious misgiving around the publication of your submission. Nevertheless, we invite you to respond to their criticisms and outline a plan of revisions that we will submit to the reviewers. If the plan is accepted, we will mark the paper as "accepted with major revisions" and give you a deadline for the revised version.

To expedite the process, we ask you to send us your proposal by 21-June-2017 with an email at the usual address

cilc2016specialissue@easychair.org

Once again, thank you for submitting your manuscript and we look forward to receiving your proposal.

Camillo & Alberto

Guest Editors

REVIEW 1

PAPER: 2 TITLE: Extending Logic Programming with Labelled Variables: Model and Semantics AUTHORS: Roberta Calegari, Enrico Denti, Agostino Dovier and Andrea Omicini

Overall evaluation: 1 (accept with minor revision)

Overall evaluation

SUMMARY: The paper extends the framework of logic programming with labelled variables, an interesting notions closely related to Gabbay labelled deductive systems. The resulting languages is expressible enough to accomodate the issues raised by the "today's pervasive systems".

Section 2 well introduce the model, with particular attention to the notion of compatibility of variables and labels. Section 3 introduces the denotational semantics, by means of the one step consequence function, which is proved to be monotone and continuous. Also an operational semantics is given that basically mimics the one of LP. Finally the denotational semantics and the operational semantics are proved to agree. Section 4 explain the implementation and Section 5 illustrates three interesting case studies.

OVERALL EVALUATION The paper does not seem to me too deep, but it is worth anyway to be published as it may have some meaningful application. Actually, I do not understand the focus on "distributed situated intelligence": in my opinion, there is no focus on "distributing at all". Actually one requires here full knowledge and a centralised programme. Something like Concurrent Constaint Programming looks to me far more "distributed".

Another weak point of the paper is the extremely poor presentation. I give some suggestions below, after a small technical issue.

TECHINAL ISSUE

In Page 3, point b, it is stated that the set of labels L is a subset of the powerset of "basic labels" B. Then the authors requires that each label should represented finitely: what does it mean in mathematical terms? Why not simplying assuming that L is contained in the finite powerset of B? On the same line, what does it mean, mathematically, that the function f_C "can argue over this representation"? I think it is important to be completely precise on this side, because it may effect the proof of continuity in Proposition 3.2.

MINOR COMMENTS AND TYPOS Page 2, second paragraph: "removing some limitations": this is Inglish. Write instead "going beyond some limitation"

Predicate symbols are not introduced, while all the other standard notion of Logic programming are. Why?

The operator f_L is required to be associative, commutative and idempotent. Is the empty-set its neutral element?

In Section 2.2, the author explain that "Head" is an atomic formula, without never explain what a formula or a predicate is...

Section 2.2: "the unification of two labelled variables ... /theta is the most general substitution". What is the most general substitution of variables? It does make much sense to me.

Table 1. The row and colums are symmetric: there is no difference between c_1,v_1,... and c_2,v_2,... but then substitution always becomes v_1/v_2. Why? Is one the head of a clause and the other an atom of the goal?

Table 1. What is a functor? The term functor has a clear mathematical meaning. In this setting it has no sense, even if I can understand what the authors mean.

Figure 1 and many other figures: I am not sure whether using figures for examples is a good typographic idea. I guess that examples should have their own proper environment.

Figure 1, line _2: "In particular, f_C(t,l) ..." --> "In particular, in our example, f_C(t,l) ..."

Section 3.1: "We define the function /tilde{f}_L that in a sense ..." which sense??? PLEASE BE FORMAL!!!!

The beginning of Page 7 "Figure 2 reports ... LP-operator" is extremely confusing. what is the standard =/2 LP operator? Are the authors explaining the meaning of =/2 in term of =LP that then you say it is just =/2 ?

Definition 3.1: What is going on in between the third and the fourth item? I do not understand.

Before Corollary 3.3. Again the authors define something in terms of something else that is not defined: uparrow omega is defined in terms of uparrow k, which is not defined (but that it would take one line to say that T_Puparrow 0 = Id and T_Puparrow (n+1) = T_P ; T_Puparrow (n+1) )

Corollary 3.3: "there is a notion of least model". Sure it always exists a notion of anything. Say: "T_P has a least fixed-point" or "T_P has a least model".

Proof of Corollary 3.3: here the author should use either Knaster-Tarski or Kleene, not both of them!

Proof of Proposition 3.4: what are "standard details"?

Page 11: "Solve/3" does not appear in Listing 1. I do not understand what are the authors referring to.

REVIEW 2

PAPER: 2 TITLE: Extending Logic Programming with Labelled Variables: Model and Semantics AUTHORS: Roberta Calegari, Enrico Denti, Agostino Dovier and Andrea Omicini

Overall evaluation: -1 (reject)

Overall evaluation

This paper presents the theoretical model of Labelled Variables in Logic Programming (LVLP).

After an introduction including two illustrative examples (WordNet and interval arithmetics) the Labelled Variables Model is introduced. It is based on the classical logic programming and the Herbrand interpretation. The LP-rules are extended by labelings, variables are assigned such labels and there are two important functions f_C and f_L, whereby f_C: H x L -> {true, false} is a _compatibility_ function to support the acceptability of labels for certain terms and f_L: L x L -> L is a _label_ _combination_ function. Beside the classical LP computation, LVLP allows a second "customizable" (somehow parallel) interpretation based on the labelings. So, labels can be interpreted as some kind of properties, categories, or attributes of terms or values, which are combined using f_L (and f_C) during resolution. Thereby, f_L can be chosen domain specific, it can not only include set operations, like union or intersection of label sets but as well e.g. arithmetic computations. A fix-point semantics and a corresponding operational semantics of LVLP are given and discussed, followed by conclusions and future work.

In general, I like this simple idea of extending logic programming by extending the variables and values by some further attributes and interpretations. However, I fear that the paper is not yet ready for publication in a journal. I miss a deeper discussion of related work, a number of potentially important points are left out (at least they should be discussed), the application area of "distributed" situated intelligence is not really motivated, and, furthermore, there are several issues in representation and layout/typing. Therefore, I opt for "-1 - reject". I will go into detail wrt. the points of criticism in the following.

Concerning related work, just one short and very general sentence "Most other works ... focus on specific scenarios ..." is given. A deeper discussion of related work is left out. Moreover, I think, that the difference of the presented approach and the mentioned other papers (last paragraph, Section 1) is not primarily that these later are "scenario specific" while LVLP is "general purpose". Some of the other approaches are as well "general purpose", but their semantics is different. Also, since the labels can be seen as some kind of category or attribute, it could make sense to check, whether there are approaches in object-oriented logic programming which could be related. Furthermore, a label could also be interpreted as a type. Types in logic programming could, thus, be some issue of related work. A similar approach, we find in functional programming by dependent types, it could be also interesting to discuss the relation of LVLP to that.

I missed an argument, why LVLP should support _distributed_ situated programming. How do you deal with distributed (potentially conflicting) computations? What about common variables in distributed systems, distributed backtracking etc.?

Further issues and point for discussion:

If it is _not_ declarative, then this would evoke serious problems concerning semantics. You would e.g. have to deal with the problem of combining declarative (timeless) and imperative (time dependent) computations. (How) Is this covered in your semantics?

of calories presupposes the existence of some (interval) arithmetics solution mechanism and concerning functions. I expect this is then realized in f_L, but it should at least be mentioned here, otherwise the computations seem somehow "magic" at this point.

just true or false? Shouldn't there happen label combinations? Please explain.

motivation of f_C. An actual example would be helpful here, by the way.

Maybe better "... ( (true/false) / f_C (theta,A), theta, A)"? Suggestion: Parenthesis for "true/false", because "false / something = false".

compute with numbers or even integer intervals. But this ist not true. The "X" in CLP(X) stands for a domain LP is extended by. You can, of course, choose for "X" other domains and solvers. The solvers, by the way, are also also necessary for your approach (to be used by f_L).

be part of I_1? If not, please explain.

the result sketched in Subsection 4.1." Is this proof then safe in its current version?

Why should LVLP support _distributed_ LP? What about distributed common variables and their bindings, distributed backtracking and the like?

We are pleased to inform you that the reviewers have recommended publication of the revised version of your paper. Please, send us an archive file containing both latex sources and the pdf of the final version, using the email address cilc2016specialissue@easychair.org

The deadline is

24th November, 2017Once again, thank you for submitting your manuscript. Camillo & Alberto Guest Editors ======================================================================

I think that the paper is now ready for publication.

The authors have implemented all the suggestions in the plans that they submitted few months ago.

In particular, I am glad to properly understand now the meaning of "distributed situated intelligence".

==========================================================================

The again revised version (2017-09-05) now covers most of the raised issues and suggestions. The most important issues - from my point of view - were (a) a more detailed discussion of related work (now to find in Section 6) and (b) an explanation of the "support of distributed situated intelligence" (now Section 2.4).

So, I would rate the paper now as "weak accept" (if this were possible). Nevertheless, I'd like to point out, that the example codes and the Figures 1 and 2 are still very much too small to read! .