Difference between revisions of "iRefIndex Development"

From irefindex
(→‎Reviewing Mapper Files: Updated output.)
(Added notes about adapting mapper files.)
Line 240: Line 240:
 
       _ouid
 
       _ouid
 
</pre>
 
</pre>
 +
 +
=== Adapting an Existing Mapper File ===
 +
 +
Given an analysis of the data and the identification of the data's "subformat" (explained above), it should be possible to take an existing mapper file which supports the same subformat and to modify it to understand the new data source. For example, the InnateDB data resembles the data of various other sources (listed in the table above), and some comparisons of the structure of the data can be performed to see which source is closest in structure to InnateDB by using a `diff`-like program, potentially a graphical program such as `kompare` or `kdiff3`.
 +
 +
Once a similar source has been identified, the corresponding mapper file can be copied and modified. For example:
 +
 +
cp mapper/Map25_CORUM.xml mapper/Map25_InnateDB.xml
 +
 +
Then, it is necessary to update the new mapper file with details that differ from those in the closest source. In some cases, it can also be useful to consult other mapper files. For example, the following path may not be present in the CORUM mapper file despite being provided by the data file:
 +
 +
entry/experimentList/experimentDescription/hostOrganismList/hostOrganism
 +
 +
However, such information can be used by iRefIndex and may be supported by other mapper files. We may therefore decide to incorporate such information into our new mapper file (and perhaps into CORUM's mapper file, too). To do so, we first inspect other mapper files for the presence of such information and then isolate the section which supports its retrieval. For example, from the IntAct mapper file, using the <tt>show_xml_paths.py</tt> script...
 +
 +
python show_xml_paths.py --mapper mapper/Map25_INTACT_MINT_BIOGRID.xml --verbose
 +
 +
Here, the <tt>--verbose</tt> flag provides identifier information which makes finding the element, table and mapping definitions easier:
 +
 +
<pre>
 +
Element experimentDescription (grouper/id=3)...
 +
 +
  [...]
 +
 +
  Table int_name (sqlref/id=23)...
 +
    _euid ...
 +
      <incremental> (provides experimentDescription)
 +
    _exorg ...
 +
      entry/experimentList/experimentDescription/hostOrganismList/hostOrganism/@ncbiTaxId
 +
    _exorgc ...
 +
      38
 +
</pre>
 +
 +
From the above, it becomes apparent that we need a <tt>group</tt> definition for <tt>elementDescription</tt>, and that <tt>int_name</tt> must be populated according to the stated mappings for <tt>_euid</tt>, <tt>_exorg</tt> and <tt>_exorgc</tt>.
 +
 +
Fortunately, a <tt>group</tt> definition already exists in our new mapper file:
 +
 +
<pre>
 +
        <group  id ="3" element ="experimentDescription" parpos="4" atrib="_AUTO_">
 +
            <path></path>
 +
            <ref choice="no" />
 +
        </group>
 +
</pre>
 +
 +
Meanwhile, the following table modifying section (corresponding to the identifier <tt>23</tt>) must be located in the IntAct mapper file:
 +
 +
<pre>
 +
        <sql id="23" userefs="no" >
 +
            <stmt>INSERT INTO int_name(uid,name,category) VALUES ('_euid','_exorg','_exorgc');</stmt>
 +
            <variablelist>
 +
                <variable name="_euid" ></variable>
 +
                <variable name="_exorg"></variable>
 +
                <variable name="_exorgc"></variable>
 +
            </variablelist>
 +
        </sql>
 +
</pre>
 +
 +
Since no conflicting section (with the same identifier for an <tt>sql</tt> element) exists in the new mapper file, this can be copied without changes. Then, it is necessary to ensure that mappings for <tt>_euid</tt>, <tt>_exorg</tt> and <tt>_exorgc</tt> are present; the following mappings happen to be found in the IntAct mapper file:
 +
 +
<pre>
 +
        <map id="42" sqlref="23"  name="_euid" grouper="3">
 +
            <instruct>
 +
                <param choice="yes" />
 +
            </instruct>
 +
        </map>
 +
        <map id="43" sqlref="23"  name="_exorg" grouper="3">
 +
            <instruct>
 +
                <readfromfile choice="yes">
 +
                    <path variable="_exorg" groupTag="ex" usetext="no" attribute="ncbiTaxId">entry,experimentList,experimentDescription,hostOrganismList,hostOrganism</path>
 +
                </readfromfile>
 +
            </instruct>
 +
        </map>
 +
        <map id="43" sqlref="23"  name="_exorgc" grouper="3">
 +
            <instruct>
 +
                <readfromfile choice="yes">
 +
                    <path variable="_exorgc" groupTag="ex" usetext="no"  prefix="yes" val="38">entry,experimentList,experimentDescription,hostOrganismList,hostOrganism</path>
 +
                </readfromfile>
 +
            </instruct>
 +
        </map>
 +
</pre>
 +
 +
Although <tt>_euid</tt> is a known name in the new mapper file already, no mapper definition exists to connect it to the table modification section (with identifier <tt>23</tt>). Thus, it is necessary to copy the above mappings, to adjust their identifiers to avoid conflicts with other mappings, and to make sure that the <tt>grouper</tt> attributes refer to the correct group definition for <tt>experimentDescription</tt>. Fortunately, no such adjustments are required in this case and the definitions can be copied directly.
  
 
== All iRefIndex Pages ==
 
== All iRefIndex Pages ==

Revision as of 14:37, 11 October 2010

See iRefIndex Issues and Notes for details of ongoing work to improve the iRefIndex software.

Adding Sources to iRefIndex

  1. Identify the location of the downloaded data.
  2. Evaluate the form of the data:
    1. For PSI MI XML (Molecular Interaction XML) documents, check the version of the format employed by the data documents.
    2. For the specific version, review the format's schema and how the data uses the schema. For example, PSI MI XML permits the specification of interactors within interaction descriptions as well as in a separate interactor list.
  3. Review existing, similar mapper definition files.

Evaluating the Data

The show_xml_paths.py script in the iRef_PSI_XML2RDBMS directory can be used to show the different element paths used in an XML data file to hold data items. For example:

python show_xml_paths.py --data /home/irefindex/data/MINT/2010-09-14/10023771.psi25.xml

The resulting list of paths indicates the places in the element hierarchy of a PSI-MI XML file where information is actually stored. For example:

entrySet/entry/experimentList/experimentDescription/attributeList/attribute
entrySet/entry/experimentList/experimentDescription/hostOrganismList/hostOrganism/names/fullName
entrySet/entry/experimentList/experimentDescription/hostOrganismList/hostOrganism/names/shortLabel
entrySet/entry/experimentList/experimentDescription/interactionDetectionMethod/names/alias
entrySet/entry/experimentList/experimentDescription/interactionDetectionMethod/names/fullName
entrySet/entry/experimentList/experimentDescription/interactionDetectionMethod/names/shortLabel
entrySet/entry/experimentList/experimentDescription/names/fullName
entrySet/entry/experimentList/experimentDescription/names/shortLabel
entrySet/entry/interactionList/interaction/attributeList/attribute
entrySet/entry/interactionList/interaction/confidenceList/confidence/unit/names/fullName
entrySet/entry/interactionList/interaction/confidenceList/confidence/unit/names/shortLabel
entrySet/entry/interactionList/interaction/confidenceList/confidence/value
entrySet/entry/interactionList/interaction/experimentList/experimentRef
entrySet/entry/interactionList/interaction/interactionType/names/fullName
entrySet/entry/interactionList/interaction/interactionType/names/shortLabel
entrySet/entry/interactionList/interaction/intraMolecular
entrySet/entry/interactionList/interaction/modelled
entrySet/entry/interactionList/interaction/names/shortLabel
entrySet/entry/interactionList/interaction/negative
entrySet/entry/interactionList/interaction/participantList/participant/biologicalRole/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/biologicalRole/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/experimentalPreparationList/experimentalPreparation/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/experimentalPreparationList/experimentalPreparation/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/experimentalRoleList/experimentalRole/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/experimentalRoleList/experimentalRole/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureRangeList/featureRange/endStatus/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureRangeList/featureRange/endStatus/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureRangeList/featureRange/isLink
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureRangeList/featureRange/startStatus/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureRangeList/featureRange/startStatus/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureType/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/featureType/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/featureList/feature/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/interactorRef
entrySet/entry/interactionList/interaction/participantList/participant/names/shortLabel
entrySet/entry/interactionList/interaction/participantList/participant/participantIdentificationMethodList/participantIdentificationMethod/names/alias
entrySet/entry/interactionList/interaction/participantList/participant/participantIdentificationMethodList/participantIdentificationMethod/names/fullName
entrySet/entry/interactionList/interaction/participantList/participant/participantIdentificationMethodList/participantIdentificationMethod/names/shortLabel
entrySet/entry/interactorList/interactor/attributeList/attribute
entrySet/entry/interactorList/interactor/interactorType/names/fullName
entrySet/entry/interactorList/interactor/interactorType/names/shortLabel
entrySet/entry/interactorList/interactor/names/alias
entrySet/entry/interactorList/interactor/names/fullName
entrySet/entry/interactorList/interactor/names/shortLabel
entrySet/entry/interactorList/interactor/organism/names/fullName
entrySet/entry/interactorList/interactor/organism/names/shortLabel
entrySet/entry/interactorList/interactor/sequence
entrySet/entry/source/attributeList/attribute
entrySet/entry/source/names/fullName
entrySet/entry/source/names/shortLabel

With this information, a suitable mapper file can be identified for the conversion of the XML-encoded data into tabular data to be stored in a database. In the above example, it is apparent that the experiment, interaction and interactor details reside alongside each other within each entry element:

entrySet/entry/experimentList/experimentDescription
entrySet/entry/interactionList/interaction
entrySet/entry/interactionList/interaction/participantList/participant
entrySet/entry/interactorList/interactor

In contrast, other PSI-MI XML files adopt a different structure which can be reduced to the following:

entrySet/entry/interactionList/interaction
entrySet/entry/interactionList/interaction/experimentList/experimentDescription
entrySet/entry/interactionList/interaction/participantList/participant

The different sources can be divided into a number of subformats as follows:

Subformat Sources Notes
Separate experiment, interaction, interactor lists BioGRID, HPRD, IntAct, MINT, OPHID BioGRID uses proteininteractor instead of interactor
OPHID uses proteinParticipant, proteinInteractor
Interaction contains experiment; separate interactor list DIP
Interaction contains experiment and interactor/participant BIND Translation, CORUM, InnateDB, MPACT, MPPI InnateDB provides apparently redundant lists of experiments and interactors
MPPI uses proteinParticipant, proteinInteractor

Reviewing Mapper Files

The mapper files already in existence can be reviewed by using the show_xml_paths.py script together with one of these files which reside in the mapper subdirectory of the iRef_PSI_XML2RDBMS directory. For example:

python show_xml_paths.py --mapper mapper/Map25_CORUM.xml

The resulting output describes the structure of the data and how the mapper will attempt to interpret that data. For example (for CORUM):

Element experimentDescription ...
  Table int_name ...
    _euid ...
      <incremental>
    _idetlbl ...
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/names/shortLabel
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/names/alias
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/names/fullname
    _idetncat ...
      24
      25
      25
  Table int_xref ...
    _euid ...
      <incremental>
    _brefdb ...
      entry/interactionList/interaction/experimentList/experimentDescription/bibref/xref/primaryRef/@db
      entry/interactionList/interaction/experimentList/experimentDescription/bibref/xref/secondaryRef/@db
    _brefid ...
      entry/interactionList/interaction/experimentList/experimentDescription/bibref/xref/primaryRef/@id
      entry/interactionList/interaction/experimentList/experimentDescription/bibref/xref/secondaryRef/@id
    _brefct ...
      4
      5
  Table int_xref ...
    _euid ...
      <incremental>
    _idetdb ...
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/xref/primaryRef/@db
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/xref/secondaryRef/@db
    _idetid ...
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/xref/primaryRef/@id
      entry/interactionList/interaction/experimentList/experimentDescription/interactionDetectionMethod/xref/secondaryRef/@id
    _idetct ...
      6
      7
Element experimentList ...
  Table int_experiment ...
    _euidr ...
      _euid
    _iuider ...
      _iuid
Element interaction ...
  Table int_name ...
    _iuid ...
      <incremental>
    _iuiflnm ...
      entry/interactionList/interaction/names/fullName
    _iuiflnmct ...
      12
  Table int_source ...
    _iuid ...
      <incremental>
    _itp ...
      entry/interactionList/interaction/xref
    _isrc ...
      entry/interactionList/interaction/xref
    _ifle ...
      entry/interactionList/interaction/xref
  Table int_xref ...
    _iuid ...
      <incremental>
    _idb ...
      entry/interactionList/interaction/xref/primaryRef/@db
    _iref ...
      entry/interactionList/interaction/xref/primaryRef/@id
    _irefcat ...
      0
Element participant ...
  Table int_name ...
    _ouid ...
      <incremental>
    _olb ...
      entry/interactionList/interaction/participantList/participant/interactor/names/shortLabel
      entry/interactionList/interaction/participantList/participant/interactor/names/alias
      entry/interactionList/interaction/participantList/participant/interactor/names/fullName
    _olbct ...
      13
      14
      15
  Table int_object ...
    _ouid ...
      <incremental>
    _oltyp ...
      entry/interactionList/interaction/participantList/participant/interactor/interactorType/names/shortLabel
    _osrc ...
      entry/interactionList/interaction/participantList/participant/interactor/names
    _ofil ...
      entry/interactionList/interaction/participantList/participant/interactor/names
  Table int_sequence ...
    _ouid ...
      <incremental>
    _obsq ...
      entry/interactionList/interaction/participantList/participant/interactor/sequence
  Table int_xref ...
    _ouid ...
      <incremental>
    _odb ...
      entry/interactionList/interaction/participantList/participant/interactor/xref/primaryRef/@db
      entry/interactionList/interaction/participantList/participant/interactor/xref/secondaryRef/@db
    _orefid ...
      entry/interactionList/interaction/participantList/participant/interactor/xref/primaryRef/@id
      entry/interactionList/interaction/participantList/participant/interactor/xref/secondaryRef/@id
    _oicat ...
      2
      3
    _otax ...
      entry/interactionList/interaction/participantList/participant/interactor/organism/@ncbiTaxId
    _otp ...
      entry/interactionList/interaction/participantList/participant/interactor/xref/primaryRef/@refType
      entry/interactionList/interaction/participantList/participant/interactor/xref/secondaryRef/@refType
Element participantList ...
  Table int_source2object ...
    _iuidr ...
      _iuid
    _what ...
      entry/interactionList/interaction/participantList/participant/interactor/names
    _isrcr ...
      entry/interactionList/interaction/participantList/participant/interactor/names
    _ifler ...
      entry/interactionList/interaction/participantList/participant/interactor/names
    _refob ...
      _ouid

Adapting an Existing Mapper File

Given an analysis of the data and the identification of the data's "subformat" (explained above), it should be possible to take an existing mapper file which supports the same subformat and to modify it to understand the new data source. For example, the InnateDB data resembles the data of various other sources (listed in the table above), and some comparisons of the structure of the data can be performed to see which source is closest in structure to InnateDB by using a `diff`-like program, potentially a graphical program such as `kompare` or `kdiff3`.

Once a similar source has been identified, the corresponding mapper file can be copied and modified. For example:

cp mapper/Map25_CORUM.xml mapper/Map25_InnateDB.xml

Then, it is necessary to update the new mapper file with details that differ from those in the closest source. In some cases, it can also be useful to consult other mapper files. For example, the following path may not be present in the CORUM mapper file despite being provided by the data file:

entry/experimentList/experimentDescription/hostOrganismList/hostOrganism

However, such information can be used by iRefIndex and may be supported by other mapper files. We may therefore decide to incorporate such information into our new mapper file (and perhaps into CORUM's mapper file, too). To do so, we first inspect other mapper files for the presence of such information and then isolate the section which supports its retrieval. For example, from the IntAct mapper file, using the show_xml_paths.py script...

python show_xml_paths.py --mapper mapper/Map25_INTACT_MINT_BIOGRID.xml --verbose

Here, the --verbose flag provides identifier information which makes finding the element, table and mapping definitions easier:

Element experimentDescription (grouper/id=3)...

  [...]

  Table int_name (sqlref/id=23)...
    _euid ...
      <incremental> (provides experimentDescription)
    _exorg ...
      entry/experimentList/experimentDescription/hostOrganismList/hostOrganism/@ncbiTaxId
    _exorgc ...
      38

From the above, it becomes apparent that we need a group definition for elementDescription, and that int_name must be populated according to the stated mappings for _euid, _exorg and _exorgc.

Fortunately, a group definition already exists in our new mapper file:

        <group  id ="3" element ="experimentDescription" parpos="4" atrib="_AUTO_">
            <path></path>
            <ref choice="no" />
        </group>

Meanwhile, the following table modifying section (corresponding to the identifier 23) must be located in the IntAct mapper file:

        <sql id="23" userefs="no" >
            <stmt>INSERT INTO int_name(uid,name,category) VALUES ('_euid','_exorg','_exorgc');</stmt>
            <variablelist>
                <variable name="_euid" ></variable>
                <variable name="_exorg"></variable>
                <variable name="_exorgc"></variable>
            </variablelist>
        </sql>

Since no conflicting section (with the same identifier for an sql element) exists in the new mapper file, this can be copied without changes. Then, it is necessary to ensure that mappings for _euid, _exorg and _exorgc are present; the following mappings happen to be found in the IntAct mapper file:

        <map id="42" sqlref="23"  name="_euid" grouper="3">
            <instruct>
                <param choice="yes" />
            </instruct>
        </map>
        <map id="43" sqlref="23"  name="_exorg" grouper="3">
            <instruct>
                <readfromfile choice="yes">
                    <path variable="_exorg" groupTag="ex" usetext="no" attribute="ncbiTaxId">entry,experimentList,experimentDescription,hostOrganismList,hostOrganism</path>
                </readfromfile>
            </instruct>
        </map>
        <map id="43" sqlref="23"  name="_exorgc" grouper="3">
            <instruct>
                <readfromfile choice="yes">
                    <path variable="_exorgc" groupTag="ex" usetext="no"  prefix="yes" val="38">entry,experimentList,experimentDescription,hostOrganismList,hostOrganism</path>
                </readfromfile>
            </instruct>
        </map>

Although _euid is a known name in the new mapper file already, no mapper definition exists to connect it to the table modification section (with identifier 23). Thus, it is necessary to copy the above mappings, to adjust their identifiers to avoid conflicts with other mappings, and to make sure that the grouper attributes refer to the correct group definition for experimentDescription. Fortunately, no such adjustments are required in this case and the definitions can be copied directly.

All iRefIndex Pages

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