having problems with a constraint on relations

[Seth Kulick]

Hi,

I have two related questions. The first concerns something I'd ideally
like to be able to do with a relation constraint, and whether it is
possible. The second concerns a workaround I tried with relation
constraints, and I cannot get it working as desired.

There are two layers in the configuration:
(1) an "entity" Span layer with a "etype" feature, a string, with a
tagset that has values PER, LOC, XXX, and some others.
(2) a "testrel" Relation layer, that is a relation on the entity
layer, with the features Source and Target

Ideally we would like to restrict testrel, so that relations can only
be between entity annotations with the same etype value, as long as
it's not XXX. So [PER, PER] and [LOC, LOC] etc. relations are
allowed, but [XXX, XXX] and all other combinations are prohibited.

So the first question - Is this something that is possible? The
documentation has an example of how to constrain the value of a
feature on a relation layer based on features of the relation
endpoints. But this is a different case - the relation layer doesn't
have a feature other than Source and Target.

As a workaround, I tried the following (restricting the etype to just
PER, LOC, XXX for testing purposes to keep it minimal)
(1) adding a "Status" feature to the testrel Relation, where Status
has a tagset with the possible values "BAD", "LOCREL", "PERREL"
(2) setting up a constraint so that if the entity types are both "PER"
then the testrel status would be "PERREL", and likewise if they are
both "LOC" then the testrel status would be "LOCREL", and otherwise
it's "BAD".
I figured that this way the annotator would see, with the "BAD" Status
value appearing first in bold, that it's an improper relation.

The attached entity_layer,.jpg, relation_layer.jpg, and
constraints.jpg show the two layers and the constraints.

However, it is not working as desired. As shown in the attached
annotation_example.jpg, I'm making a relation between two XXX
entities, and it shows PERREL as the selected status. I've tried
this several times with fresh projects and restarts, and what seems to
be happening is that whatever the first relation label is, it retains
that for all future suggestions (before the example show in
annotation_example, I had done an annotation between two PER, and it
had indeed properly selected PERREL as the Status). One other
datapoint that maybe is of interest - The constraints do not
currently cover all the possible cases - e.g. there is no condition
for a [LOC, PER] or [PER, LOC] condition setting Status to BAD. And,
interestingly, when I try that case, it does not show the Status menu
at all, which is the expected behavior I think since I have "Show only
when constraints turned on" for the Relation layer - so it is indeed
reading and processing the constraint file, but for whatever reason
not setting Status correctly.

I've checked and rechecked the names being used. Is there some simple
typo or error that I'm not seeing, or maybe misunderstanding how this
is supposed to work?

Some other questions that arose while doing this:
(A) I have "Required" selected for the Status feature for the
relation, and the Status feature is set to a tagset that has just BAD,
LOCREL, PERREL. But yet, even when a Status is not selected, it
displays "testrel" (the name of the relation) on the arc, and lets me
make the relation If a Status is selected, it displays that instead
of "testrel" on the arc. If Status is "Required", why does it let me
make Relations without a Status selected?
(B) There is a "Default value" field for the Status feature. I
couldn't find anything in the documentation about this. How is this
meant to be used? It doesn't seem to be tied to the tagset options
for the feature.

I've tried the above with both 40.1 and 40.4.

Sorry, that was a lot. I hope it was clear. Thanks for your help.


Seth

[Richard Eckart de Castilho]

Hi Seth,

thanks for the in-depth explanation. Defining a constraint without
a feature is not possible. Regarding your workaround - it sounds
plausible.

You could greatly help me looking into this by opening a bug report
and attaching a reproducer project to it. That would be much easier
for me than having to reconstruct the project from your screenshots.

https://github.com/inception-project/inception/issues/new/choose

The reproducer should be simple and not include any private data since
it will be publicly accessible from the bug report.

If you could do that please, I would be very thankful.

Cheers,

-- Richard