clarification on SRL constraints

[danyaljj]

@kordjamshidi a question for you:

In this line, I am confused about the order between and and ==>. Which one of the followings is the correct one?:

1. Conjunction of implications:

 a = a and  (   ((argumentTypeLearner on t) is values(i)) ==>
        argCandList.filterNot(x => x.equals(t))._exists {
          k: Relation => (argumentTypeLearner on k) is values(i).substring(2)
        }  )

1. Conjunction and then implication:

 a = (  a and ((argumentTypeLearner on t) is values(i))   ) ==>
        argCandList.filterNot(x => x.equals(t))._exists {
            k: Relation => (argumentTypeLearner on k) is values(i).substring(2)
       }

To me (1) makes more sense, although I think in practice it's being treated as (2).

[danyaljj]

@kordjamshidi do you have any ideas for this?

[kordjamshidi]

I think I meant to have implications to be conjuncted. So, 1. Why do you think " in practice it's being treated as (2)."?

[danyaljj]

Got it. I'll test in practice and will come back to you.

[kordjamshidi]

close the issue if this is solved then.

[danyaljj]

A couple of more clarification questions:

1. How should I interpret the following?:
   firstOrderRule isNot firstOrderRule

One example is used here.

2. I am confused how I should interpret arg_IdentifierClassifier_Constraint.
   It says argumentXuIdentifierGivenApredicate says a given constituent not NOT an argument, then argumentTypeLearner should argumentTypeLearner should predict candidate. Why does it make sense?

 val arg_IdentifierClassifier_Constraint = ConstrainedClassifier.constraint[Relation] {
    x: Relation =>
        (argumentXuIdentifierGivenApredicate on x isNotTrue) ==>
          (argumentTypeLearner on x is "candidate")
  }

[kordjamshidi]

1. isNot: if you look at the definition, this is the opposite of is (first order equality) and it means isNot equal, the output of the two classifiers should not be equal. I am not sure why this is unclear. Could you mention what is ambiguous here?
2. if some thing is not an argument (argument identifier says false) then the argument type classifier should not predict any type for it. So the prediction of argument identifier and argument type classifier should be consistent. (note: candidate means none of the types)

[danyaljj]

1. ok. makes sense.
2. Ah I didn't know that "candidate means none of the types". Got it.

[danyaljj]

@kordjamshidi question: Here we have:

(argumentTypeLearner on z is "candidate")

while the label set of argumentTypeLearner is:

Set(R-A4, C-AM-CAU, AM-PRD, C-A1, A4, C-AM-LOC, R-AM-TMP, C-AM-ADV, AM-ADV, AM-LOC, C-A5, C-AM-MNR, AM-TMP, C-A0, A5, R-AM-LOC, C-AM-DIS, C-A4, AA, AM-NEG, C-AM-EXT, R-A0, C-AM-DIR, AM-EXT, AM-with, C-V, AM-DIR, C-A3, A2, C-AM-NEG, AM-on, R-AM-PNC, C-AM-TMP, A1, R-A1, R-AM-CAU, AM-at, R-A2, AM-MOD, AM-PNC, AM-in, R-AM-ADV, AM-by, AM-MNR, C-AM-PNC, R-A3, R-AM-MNR, A3, AM-for, C-A2, AM-CAU, R-AA, AM-against, AM-DIS, A0, AM-REC, R-AM-EXT)

isn't it a bug?

[danyaljj]

@kordjamshidi

[kordjamshidi]

Ok let me finish the PR comments, will be here soon.

[kordjamshidi]

why a bug? It says, the argument should be legal or none.

[danyaljj]

Can the classifier argumentTypeLearner have prediction of candidate?

[kordjamshidi]

I think you forgot this: candidate means none.

[danyaljj]

I got your previous point that:

if some thing is not an argument (argument identifier says false) then the argument type classifier should not predict any type for it. So the prediction of argument identifier and argument type classifier should be consistent. (note: candidate means none of the types)

What I am saying is that, the constraint of

(argumentTypeLearner on z is "candidate")

can never be true (I think), because argumentTypeLearner simply does not have such label, i.e. its output label-set does not contain "candidate".

[kordjamshidi]

why it can not? where we have defined the set of allowables for it? maybe I miss something here.

[kordjamshidi]

wait! from where you copied that set above? Although this is the set of types in the problem but we did not explicitly defined this for argument type learner.

[danyaljj]

wait! from where you copied that set above?

The set I have mentioned above, I printed programmatically; I simply printed the label-lexicon of the classifier.

Although this is the stet of types in the problem but we did not explicitly defined this for argument type learner.

What do you mean by: "we did not explicitly defined this for argument type learner."?

[kordjamshidi]

it builds the label lexicon based on what it gets and it can get the candidate as a possible lable value too in a way that we have designed it.

[danyaljj]

it can get the candidate as a possible lable value too in a way that we have designed it.

If you load the trained models from disk, they don't candidate in the label lexicon. And if it hasn't seen candidate in the training set, then it will never predict candidate.

[kordjamshidi]

I am not sure if I understand your point. This can happen if the model has trained using the gold boundaries, meaning it gets only identified agruments and predcits their types. Even in this case there is an or there in the constraint, so it just needs to predict a legal type because the other part of the or is always false for such a case. So the constraint still is valid I guess.

[danyaljj]

Let me paraphrase what you said, and see if this is correct:

For models trained with useGoldBoundaries, label-lexicon should contain candidate.

Did I get it correct?

[kordjamshidi]

Just the reverse: For models trained with useGoldBoundaries=false, label-lexicon should contain candidate