SBML.org — the global portal for all things SBML

Precedence

Contents

Nesting of Qualifiers (Predicates)

To put it more simply, let's say we have protein complex A that has components B and C. One version of protein B is called protein B1. In this case, you would first say that A hasParts B and C, and that there isVersion of B called B1. Alternatively (and equally) you could say that A hasVersion complex A1 which hasPart B1. Which choice do we make?

[DW] Reading the example with the two versions, I would not agree on that. For me there is a difference in the knowledge you transfer by saying

A hasParts (B and C) AND B1 isVersion B

and saying:

A hasVersion A1 AND A1 hasPart B1

In the second case you say that you have another version of A which is called A1. You do not *know* of that version A1 in the first case. It does not exist. In the first case you do not necessarily say that B1, which is a version of B, is actually part of A - you could have both expressions, but they do not *mean* that B1 is part of A in the first case, while it does in the second...

  • Such statements can be made normally in RDF, as RDF is all about creating graphs, or lists of triples.
  • But how much RDF do we allow? In the controlled annotation section, we limit RDF so that software only has to support some of it. There are a number of reasons for not allowing complete RDF
    • Any software tool would need a complete RDF Parser
    • More importantly, it is difficult to compare two bits of arbitrary RDF and determine that they make the same statement. For example, the A/B/C example above could be written in the two ways discussed above, and also in a number of other ways once you decide to have blank nodes / identified notes etc. (We believe precedence is the way to resolve this, or mostly resolve this.)
  • We could, for instance, replace hasPart with either an rdf Container or rdf Collection (open world or closed world). However, hasPart has a biological meaning that the RDF does not have; hasPart is something that researchers are familiar with; and indeed hasPart might be a complete OR an incomplete list.

Answer

There are several RDF snippets below, exemplifying different way of nesting annotations. All those examples are different.

Example 1

unbounded list of parts, each with alternative versions

The example 1 starts with a hasPart qualifier which references two generic proteins, and then provides specific version possibilities for each of these generic proteins. We do not know which specific version of one assembles to to which specific version of the other. Please note that hasVersion does not imply that all versions are listed, but that these are at least 3 possible versions of GP1 and 2 of GP1.

         <rdf:Description rdf:about="#metaid_0000008">
            <bqbiol:hasPart>
              <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:genericProtein1" rdf:ID="GP1"/>
                <rdf:li rdf:resource="urn:miriam:genericProtein2" rdf:ID="GP2"/>
              </rdf:Bag>
            </bqbiol:hasPart>
         </rdf:Description>
         <rdf:Description rdf:about="#GP1">
           <bqbiol:hasVersion>
            <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:uniprot:P12345"/>
                <rdf:li rdf:resource="urn:miriam:uniprot:P12344"/>
                <rdf:li rdf:resource="urn:miriam:uniprot:P12333"/>
            </rdf:Bag>
           </bqbiol:hasVersion>
         </rdf:Description>
         <rdf:Description rdf:about="#GP2">
           <bqbiol:hasVersion>
            <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:uniprot:P54321"/>
                <rdf:li rdf:resource="urn:miriam:uniprot:P54322"/>
            </rdf:Bag>
           </bqbiol:hasVersion>
         </rdf:Description>

Example 2

Unbounded list of alternative versions of a complex, each made of an unbounded list of parts

Example 2 starts instead by stating that a species could be the versions listed in the hasVersion qualifier (though isn't necessarily limited to these named versions), and then lists the specific parts for each version.

There is no way to write Example 1 in the style of this Example and make them semantically equivalent: even if you put in all possibilities, that doesn't work as you would be saying that all possibilities exist, and there is no way of knowing that. Therefore we must allow both styles, and we cannot enforce a particular preference.


         <rdf:Description rdf:about="#metaid_0000008">
            <bqbiol:hasVersion>
              <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:specificComplex1" rdf:ID="SC1"/>
                <rdf:li rdf:resource="urn:miriam:specificComplex2" rdf:ID="SC2"/>
              </rdf:Bag>
            </bqbiol:hasVersion>
         </rdf:Description>
         <rdf:Description rdf:about="#SC1">
           <bqbiol:hasPart>
            <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:uniprot:P12345"/>
                <rdf:li rdf:resource="urn:miriam:uniprot:P54321"/>
            </rdf:Bag>
           </bqbiol:hasPart>
         </rdf:Description>
         <rdf:Description rdf:about="#SC2">
           <bqbiol:hasPart>
            <rdf:Bag>
                <rdf:li rdf:resource="urn:miriam:uniprot:P12344"/>
                <rdf:li rdf:resource="urn:miriam:uniprot:P54322"/>
            </rdf:Bag>
           </bqbiol:hasPart>
         </rdf:Description>

Example 3

Bounded list of alternative versions of a complex, each made of an unbounded list of parts

This is a specific subset of Snippet 2 that shows how to limit the versions ONLY to those specified (a closed-world rather than open-world solution).

         <rdf:Description rdf:about="#metaid_0000008">
           <bqbiol:hasVersion rdf:parseType="Collection">
               <rdf:Description rdf:ID="SC1"/>
               <rdf:Description rdf:ID="SC2"/>
           </bqbiol:hasVersion>
        </rdf:Description>
        <rdf:Description rdf:about="#SC1">
          <bqbiol:is>
           <rdf:Bag>
               <rdf:li rdf:resource="urn:miriam:specificComplex1"/>
           </rdf:Bag>
          </bqbiol:is>
          <bqbiol:hasPart>
           <rdf:Bag>
               <rdf:li rdf:resource="urn:miriam:uniprot:P12345"/>
               <rdf:li rdf:resource="urn:miriam:uniprot:P54321"/>
           </rdf:Bag>
          </bqbiol:hasPart>
        </rdf:Description>
        <rdf:Description rdf:about="#SC2">
          <bqbiol:is>
           <rdf:Bag>
               <rdf:li rdf:resource="urn:miriam:specificComplex2"/>
           </rdf:Bag>
          </bqbiol:is>
          <bqbiol:hasPart>
           <rdf:Bag>
               <rdf:li rdf:resource="urn:miriam:uniprot:P12344"/>
               <rdf:li rdf:resource="urn:miriam:uniprot:P54322"/>
           </rdf:Bag>
          </bqbiol:hasPart>
        </rdf:Description>

Conclusion

Conclusion: We do not need to implement any precedence rules.

Below was our original discussion, when we thought that by forcing precedence, it becomes possible to actually compare two bits of RDF so that they can be determined to be equal. However, ultimately we decided that in all of our examples we didn't want to enforce a precedence because writing the graph different ways actually has different semantics.

  • When you have 1 element that is annotated with several qualifiers and several bags, some are more important (biologically or from the standpoint of the model) than others, there is no way to currently capture that using the SBML Specification. This precedence is reported in the BioModels Database Annotation Tips as:
There is only one level of explicit qualification. In addition, an implicit hasVersion is embedded in the sets. If there are two sets of hasPart annotations, both sets are alternative complexes made-up of their parts. When the exact description of the relation between a model component and its annotation would require combination of several qualifiers, a precedence has to be established: 1) hasPart has precedence over hasVersion 2) isPartOf has precedence over isVersionOf 3) hasPart has precedence over isHomologTo.
  • Another reason to do this is to help tools which put weightings on particular types of annotation (to say which is more important). It would be nice to directly encode this precedence in a way accessible to tools. This is useful for comparing two models by looking at their annotation. Such weightings could be helpful.

Retrieved from "http://sbml.org/Events/Other_Events/Annotation_package_workshop_2010/Annotation_Precendence/Precedence"

This page was last modified 12:12, 18 June 2010.



Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 12:12, 18 June 2010.