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

SyBiOnt Extension: New Compound predicates #7

Open
chrisAta opened this issue Jan 29, 2018 · 2 comments
Open

SyBiOnt Extension: New Compound predicates #7

chrisAta opened this issue Jan 29, 2018 · 2 comments

Comments

@chrisAta
Copy link

NOTE: These are abstractions of terms I think should be added, not absolutes. The details of these implementations, especially naming, are definitely up for debate, please give feedback!

Compound -> compoundCharge -> ("integer")^^xsd:integer
Compound -> compoundFormula ("string")^^xsd:string
Compound -> SMILES ("string")^^xsd:string

These two new predicates would simply make it possible to describe a compound with even more detail. The SMILES predicate in particular would make it possible to do string searches based on certain chemical groups that we might want present.

@djskelton
Copy link

  • Agree about charge.

  • Compound formula could be added, but I question what value this adds (when you have the SMILES).

  • I agree that SMILES needs to be in there. However, we need to (perhaps?) be more specific; SMILES strings are not unique (multiple strings can be used to represent the same structure, and different tools will 'canonicalize' these differently), meaning that string matching cannot be used for searching. Similarly, we need to decide between isomeric SMILES and non-isomeric SMILES.

  • I would recommend adding standardized InChI strings -- if I recall, these can uniquely represent a compound (although, not tautomers of the same compound).

@goksel
Copy link
Contributor

goksel commented Feb 5, 2018

I would suggest using Charge rather than compoundCharge. These properties all belong to the Compound class anyway. If we end up using this property for some other class, we can still use "charge".

Rather than SMILES as a property, why don't create a Formula class with encoding "type" and "value" as the properties. We can then associate InChi values similarly.

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

No branches or pull requests

3 participants