Difference between revisions of "iRefIndex Testing 7.0"

From irefindex
Line 84: Line 84:
 
|  
 
|  
 
|}
 
|}
 +
 +
===UID overlap testing===
 +
After parsing it is important to make sure there is no overlap in the UID:
 +
The following queries should return empty set:
 +
 +
*select * from int_object where int_object.uid in (select uid from int_source)
 +
*select * from int_object where int_object.uid in (select uid from int_experiment)
 +
*select * from int_source where int_source.uid in (select uid from int_experiment)
 +
 +
  
 
Follow this link for a listing of all iRefIndex related pages (archived and current).
 
Follow this link for a listing of all iRefIndex related pages (archived and current).
 
[[Category:iRefIndex]]
 
[[Category:iRefIndex]]

Revision as of 09:29, 28 November 2010

The testing procedure for iRefIndex

Cross check with output of element counter

Program to use : biotek.uio.no.XML.Element_Counter (SaxValidator package)

  • For each interaction source </interactor> count should match the UID count int_object (select (select name from int_db where int_db.id=source) as intSource, count(uid) from int_object group by source; ).
  • For each interaction source </interactor> count should match the UID count int_source (select (select name from int_db where int_db.id=source) as intSource, count(uid) from int_source group by source;).
  • When </interactor> is not usable to count distinct objects (when this occurs as part of interaction and repeated in interactorList) some other suitable element has to be used (e.g </participant>)
  • Why count the closing elements in the above cases (e.g. </interactor> , instead of <interaction> or </interaction ). The reason is interaction elements may have attributes and elements starting with interaction may be ambiguous. This program uses text matching (to be independent of any XML parsing).


Check SEGUID. Check one record each to very the process worked

Test SEGUID updating process

*SQL query = select orid, count(distinct rog) as rog_C from seguid where orid<0 group by orid;
orid Record_count
-30 16983
-26 2
-24 78
-23 14
-22 1043258
-21 669761
-12 2679
-11 1665
-8 6525
-7 6547
-6 5235
-5 50305
-3 10853842
-2 11972291
  • All entries with orid<0 are altered during update. All interies with orid>=0 are original entries from seguid annotation file.
ORID Description
-30 This is a iRefIndex Complex (RIGID used as ROGID), included in a previous process
-26 Is a OLN dead yeast_acc mapped using UniProt cross reference
-25 Is a SGD acc dead yeast_acc mapped using UniProt cross reference
-24 Is a dead fly_acc mapped using UniProt cross reference
-23 Is a dead PDB
-22 Is a dead RefSeq
-21 Is a dead UniProtKB
-12 Added to SEGUID from original sequence record (N-Scores) in a previous process
-11 Added to SEGUID using Eutils in a previous process
-8 Is a live OLN acc yeast_acc mapped using UniProt cross reference
-7 Is a live SGD acc yeast_acc mapped using UniProt cross reference
-6 Is a live fly_acc mapped using UniProt cross reference
-5 Is a alive PDB
-3 Is a alive RefSeq
-2 Is a alive UniProtKB

UID overlap testing

After parsing it is important to make sure there is no overlap in the UID: The following queries should return empty set:

  • select * from int_object where int_object.uid in (select uid from int_source)
  • select * from int_object where int_object.uid in (select uid from int_experiment)
  • select * from int_source where int_source.uid in (select uid from int_experiment)


Follow this link for a listing of all iRefIndex related pages (archived and current).