@colleenXu, the latest data was released to the CI environment.

I'm looking at the current CI responses now...

I think there's a parsing issue with subject.uniprot.secondary_accession. In this document, it looks like the 1-string-element should have been split for each value "B4DYS6 D3DVV8 P19138 P20426 Q14013 Q5U065". Compare it to the same document in ncats.io.

Regarding problem 1 (relation.bindingdb_link urls not reaching the actual webpages)...

This seems to be addressed in CI! It looks like enzyme names were updated, which meant the webpage urls also needed to be updated.

• in my opening post, I pointed out this record with this problematic bindingdb_link. And the current CI's corresponding record has a different bindingdb_link that works! The only diff I see in the urls is the enzyme name.
• I found another example of a record with a problem bindingdb_link. And the current CI's corresponding record has a different bindingdb_link that works!

Regarding problem 2 (object field values are incorrect/problematic/outdated)...

Some problems were addressed in CI!

• object.chembl: multiple IDs now seem to be correctly split. I checked all previous examples. Note that I still haven't checked how reliable/accurate these IDs are.
• object.name: multiple values now seem to be correctly split

One idea is double-check how reliable the chembl IDs are, and if they're good, to switch BTE/x-bte annotation to using it rather than inchikey (current)/pubchem_cid (previous).

However, this would decrease our coverage of this resource to <50% (old breakdown's proportions are still roughly correct).

Some problems still exist. We may have to dig deeper into the data/parser to figure these out...

• object.pubchem_cid: all "incorrect" values are still there (more details in another post)
• object.inchikey: all "incorrect" values are still there.

And a note: problem 3 (optional, more specific relationships) hasn't been addressed yet.

I'm looking at the current CI responses now...

I think there's a parsing issue with subject.uniprot.secondary_accession. In this document, it looks like the 1-string-element should have been split for each value "B4DYS6 D3DVV8 P19138 P20426 Q14013 Q5U065". Compare it to the same document in ncats.io.

Hi @colleenXu,

Now, the field subject.uniprot.secondary_accession has the values split for each value.

It's deployed to the CI environment. Let me know if it is as expected.

@everaldorodrigo

subject.uniprot.secondary_accession now looks wrong in a different way.

Sometimes the array's last value is an array (a duplication happening somewhere)? Examples:

• this record
• these records

good catch @colleenXu !

Also want to mention that this kind of parsing issue can be identified at its early stage if we run the inspect step after the data upload. It should warn a field if its values have mixed data types. @everaldorodrigo