Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename inverse relations flag #1093

Draft
wants to merge 5 commits into
base: master
Choose a base branch
from
Draft

Rename inverse relations flag #1093

wants to merge 5 commits into from

Conversation

mberr
Copy link
Member

@mberr mberr commented Aug 27, 2022

Cherry pick from #752 to reduce diff, as well as consistent renaming across all files.

note: the large number of changed files is partially caused by the experimental configurations

With the upcoming changes from #752, there will no longer be the need to create inverse triples, and only the relation representations will have the artificial relations introduced by inverse relations.

@mberr mberr changed the title Rename flag & adapt lightning code Rename inverse relations flag Aug 27, 2022
@cthoyt
Copy link
Member

cthoyt commented Aug 29, 2022

Are we sure this is worth the massive diff and backwards incompatibility?

model=model,
model_kwargs=dict(embedding_dim=embedding_dim, loss=loss),
model_kwargs=dict(embedding_dim=embedding_dim, loss=loss, use_inverse_relations=use_inverse_relations),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this correct? shouldn't it still be in the dataset_kwargs before #752?

@cthoyt
Copy link
Member

cthoyt commented Jan 15, 2023

Originally I wasn't so keen on this because I was worried about backwards compatibility issues, but I think we can throw that to the wind. BUT, I still think there are a lot of spurious changes here that will just get deleted in the next PR, so can't we just do #752 first without the name change, then do a second (much smaller) PR after that updates the names?

@mberr
Copy link
Member Author

mberr commented Jan 15, 2023

Originally I wasn't so keen on this because I was worried about backwards compatibility issues, but I think we can throw that to the wind. BUT, I still think there are a lot of spurious changes here that will just get deleted in the next PR, so can't we just do #752 first without the name change, then do a second (much smaller) PR after that updates the names?

Yes, should be fine, too.

We should remember to update the configs, too 🙂

We could add some logic to loading configurations to either map the old name to the new one, or warn about it linking to this issue / how to fix old configs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants