🧨 💎 Add literal interaction and outline for tests

[cthoyt]

Closes #244. This PR is part of the break-up effort on #107.

This PR implements literal interaction modules, which wrap another interaction module as well as a "combination" function, which takes the representations for the entities and representations for literals and creates a combined representation (implementation up to user - the simplest is to concatenate them).

There's a bit of goofiness to the typing since it's hard to express types dynamically - this makes it difficult to think about any other kind of interaction function besides simple ones that give single embeddings for head, relation, and tail.

Before Merge

• Make tests work!
• Do we need regularizers for LiteralE in general, or for DistMultLiteral or ComplExLiteral?
• Should we reorganize the Combination class to take the unconcatenated representations?

[cthoyt]

@mberr note the dropout comes after the linear later for distmult but before for complex. was this correct?

[cthoyt]

this needs to be written up a bit differently - no regularization was reported for this model, right? so it's time to remove it

[mberr]

Maybe, we should use a mixin here?

Maybe something like this

class EntityCombinationMixin(Interaction):
    def __init__(self, combination: Callable[..., torch.Tensor], *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.combination = combination

    def forward(self, h, r, t):
        h = self.combination(h)
        t = self.combination(t)
        return super().forward(h=h, r=r, t=t)

class LinearProjectionCombination(EntityCombinationMixin):
    def __init__(self, embedding_dim, num_of_literals,, *args, **kwargs):
        self.projection = nn.Linear(embedding_dim + num_of_literals, embedding_dim)
        super().__init__(combination=lambda x: self.projection(torch.cat(x, dim=-1)), *args, **kwargs)


class DistMultLiteral(EntityCombinationMixin, DistMultInteraction):
    pass

[cthoyt]

Maybe, we should use a mixin here?

Maybe something like this

class EntityCombinationMixin(Interaction):
    def __init__(self, combination: Callable[..., torch.Tensor], *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.combination = combination

    def forward(self, h, r, t):
        h = self.combination(h)
        t = self.combination(t)
        return super().forward(h=h, r=r, t=t)

class LinearProjectionCombination(EntityCombinationMixin):
    def __init__(self, embedding_dim, num_of_literals,, *args, **kwargs):
        self.projection = nn.Linear(embedding_dim + num_of_literals, embedding_dim)
        super().__init__(combination=lambda x: self.projection(torch.cat(x, dim=-1)), *args, **kwargs)


class DistMultLiteral(EntityCombinationMixin, DistMultInteraction):
    pass

cool idea, but let's make sure the typing is done right. The h = cat(h) line is super non-intuitive if you don't realize that before h is a pair of embeddings

[mberr]

cool idea, but let's make sure the typing is done right. The h = cat(h) line is super non-intuitive if you don't realize that before h is a pair of embeddings

I am not sure whether the cat should be part of the "interface", or whether we should keep it like above, where linear(cat(...)) is one of the possible combination choices.

[cthoyt]

@mberr you're thinking convolution too, right? I'm not the only one thinking that would be cool (but probably ultimately not helpful 😆 )

[mberr]

Do we need to make sure that "e" is unused?

[cthoyt]

yes, there needs to be an extra dimension floating around here that gets added in by the literal model

[cthoyt]

Added more docs for this in c7b9bc1

[mberr]

no need for view(-1) here?

[cthoyt]

it works without it... sooooooo... you tell me

[mberr]

besides, looks good to me! Great to have them integrated into testing.