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

InChIKey property #466

Closed
wants to merge 7 commits into from
Closed
Changes from 3 commits
Commits
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
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>`_
vaitkus marked this conversation as resolved.
Show resolved Hide resolved
Copy link
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?

Copy link
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.

Copy link
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