[Copilot]

Add Wikidata lookups from compound names and CAS numbers to CAS, compound name, InChI, and InChIKey.

• Queries: Use Wikidata EntitySearch for names and property P231 for CAS numbers; return available P231, P234, and P235 values.
• Integration: Export the converter, include it in Galaxy options, and document it.

converter = Wikidata(session)
inchikey = await converter.compound_name_to_inchikey("aspirin")
name = await converter.casno_to_compound_name("50-78-2")

• Fixes Add additional module for wikidata #173

[hechth]

@copilot also add non-mocked tests for aspirin
name: aspirin
canonical_smiles: CC(=O)OC1=CC=CC=C1C(=O)O
cas: 50-78-2
pubchem_id: 2244

[Copilot]

@copilot also add non-mocked tests for aspirin
name: aspirin
canonical_smiles: CC(=O)OC1=CC=CC=C1C(=O)O
...

Added live, non-mocked aspirin lookups by name and CAS, and included canonical SMILES and PubChem CID (P233/P662) in the returned fields. Committed as 830749f. The tests could not be run here because pytest is unavailable and Wikidata access is blocked.

[hechth]

@marvinm2 could you give the SPARQL queries a review and see if that fits?

[hechth]

@copilot add additional conversions, starting from wikidataid and pubchemid, as well as inchi and inchikey

[Copilot]

@copilot add additional conversions, starting from wikidataid and pubchemid, as well as inchi and inchikey

Added conversions from Wikidata QIDs, PubChem CIDs, InChI, and InChIKey to the available Wikidata attributes, with mocked query tests and live aspirin cases. Committed as c58e3ba.

[hechth]

@copilot look at the other web converters and implement the same caching method in case multiple attributes are queried across jobs

[Copilot]

@copilot look at the other web converters and implement the same caching method in case multiple attributes are queried across jobs

WebConverter.query_the_service already provides async LRU caching inherited by Wikidata. Added a regression test showing separate attribute conversions for the same name share one underlying request. Committed as 8f361d1.

[marvinm2]

I ran the queries against query.wikidata.org. They return the right values for aspirin, but two of them are slow.

from_casno and from_identifier match with FILTER(?casno = ...) / FILTER(STR(?identifier) = ...), so Blazegraph scans every value of the property. For aspirin that took 27 s (CAS), 28 s (PubChem CID) and 16 s (InChIKey). Putting the value in the triple pattern gives the same result in about 0.2 s:

?item wdt:P231 "50-78-2" .
?item wdt:{property_id} {self.sparql_literal(value)} .

P231, P662, P234 and P235 are plain string literals, so the STR() isn't needed. WDQS has a 60 s timeout and a per-client limit on query time, so I'd expect the current version to start failing on larger batches.

The name search takes the first EntitySearch hit without checking that it's a chemical. "mercury" returns Q613883, and the element (Q925) is only the fifth hit. Asking for more hits and keeping the first one with a chemical identifier fixes that:

  mwapi:limit "20" .
  ?item wikibase:apiOutputItem mwapi:item .
  ?ord wikibase:apiOrdinal true .
}
FILTER EXISTS { ?item wdt:P231|wdt:P235|wdt:P233 [] }
...
ORDER BY ?ord
LIMIT 1

Smaller thing: LIMIT 1 without ORDER BY gives an arbitrary row when an item has several values. 323 items have more than one CAS number, and about 1,500 InChIKeys are shared by more than one item. Adding an ORDER BY would make results deterministic.

The QID lookup is fine, and using wdt: (best rank only) is the right choice.