Skip to content

InChIKey property #466

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.

Sign up for GitHub

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

Closed
merkys wants to merge 7 commits into from
Closed

InChIKey property #466

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
1b8fe69
Add `inchikey`.
merkys Jun 7, 2023
4148d3b
Update optimade.rst
merkys Jun 8, 2023
0a3b3aa
Update optimade.rst
merkys Jun 8, 2023
423da1a
Replace "representation" with "identifier".
merkys Jun 8, 2023
041d04b
Add a disclaimer about non-uniqueness of InChIKey.
merkys Jun 8, 2023
14f33a9
Update optimade.rst
merkys Jun 9, 2024
0ab8ba8
Update optimade.rst
merkys Jun 10, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions optimade.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2500,6 +2500,20 @@ chemical\_formula\_anonymous

- A filter that matches an exactly given formula is :filter:`chemical_formula_anonymous="A2B"`.

inchikey
~~~~~~~~

- **Description**: The standard InChIKey representation of the structure, as laid out by the `InChI Trust <https://www.inchi-trust.org>`_
Comment thread
vaitkus marked this conversation as resolved.
Outdated

@vaitkus vaitkus Jun 8, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Maybe we should also specify which InChI/InChiKey version should be used?

@merkys merkys Jun 8, 2023

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Fair point. I would also like to discuss how will we handle deprecation and switching to new InChiKey versions in the future, as I do not believe it will be possible to keep using the old version when new ones are released. I can think of the following options:

  1. When InChiKey version changes, put the newest version in the upcoming OPTIMADE specification vX and require all implementers of vX to recompute their InChiKey.
  2. Define the InChiKey version as metadata (after Adding per property meta_data field. #462 gets solved).

First solution is better for interoperability, but puts more strain on the implementers.

@vaitkus vaitkus Jun 8, 2023

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think that for now we should go with option 1 since this approach is already used in the suggested SMILES property (PR #392). Later on when (and if) the metadata approach gets merged, option 2 can be revisited.

However, I think that option 1 greatly simplifies queries for the client. Each time needing to calculate the InChIKey with several different versions of the algorithm to just to query several databases does not seem very convenient.

- **Type**: string
- **Requirements/Conventions**:

- **Support**: OPTIONAL support in implementations, i.e., MAY be :val:`null`.
- **Query**: Support for queries on this property is OPTIONAL.

- **Examples**:

- Morphine: :val:`BQJCRHHNABKAKU-KBQPJGBKSA-N`

dimension\_types
~~~~~~~~~~~~~~~~

Expand Down