SBML.org — the global portal for all things SBML

Booleans

Contents

A value was tested for and not found / A reaction was deliberately not used

  • Example 1: A modeller has deliberately not included a particular reaction/pathway, and so software tools that may wish to add reactions should ignore those the modeller has already discounted. ("Don't remind me again" button in the software tool.)
  • Example 2: Components that have been considered, but can be proven to NOT be there.

Initial discussions

To add these exclusions, we can think of two ways to provide a solution.

Solution 1: A combination of:

  • some new qualifier such as bqmodel:bypass/bqmodel:omitted which would say that any MIRIAM URIs in the bypass should be ignored, and
  • annotation on annotation (see other topic) that would describe why the bypass was applied. In Example 1, the reason would be because the modeller decided an existing reaction (for example) was not appropriate for this model, and for Example 2, the reason would be because there was experimental evidence that a previously-described reaction in fact does not exist.
    • Note: evidence codes such as those provided by Evidence code ontology were considered as a method of annotating why an annotation was disregarded, but it was pointed out that these only describe where the evidence came from, but not why they were added or removed, e.g. "not necessary in this model because of modeller preference" or "not included in this model because it was tested for and not found" are not part of the ontology

Solution 2: A choice of either:

  • some new qualifier such as bqmodel:bypass/bqmodel:omitted which would say that any MIRIAM URIs in the bypass should be ignored because, while the component exists, it is not appropriate for this model, or
  • some new qualifier such as bqmodel:doesnotexist which would say that any MIRIAM URIs in the bypass should be ignored because they have been experimentally proven not to exist (where they were once thought to exist, for example).

The placement of the annotation would determine in what context the components should be omitted. For example, placing the annotation under the Model element would imply a scope of the entire model, while placing under a compartment element would imply that those URIs should not be included as part of that compartment.

There is no suitable way to have negation in RDF itself, though people have been writing something called ERDF (Extended RDF) that includes negation. This may be useful to look at in future.

Extensions to the Specification

The above requires a few modifications/extensions to the existing specification:

  1. The use of rdf:ID for all valid rdf elements in the SBML specification
  2. The use of more than one rdf:Description element for controlled annotations.
  3. The use of rdf:parseType = collection for those qualifiers where we want to assume closed-world, and the formatting differences that arise from this.
  4. The use of rdf:alt. However, do we allow ordering of rdf:alt (this is in the RDF specification, but we may wish to not allow that in our annotation).


Implicit logical statements discussion

Using RDF bags and bqbiol identifiers, implicit logical statements can be created.

Nesting of Bag/Alt/Seq (Objects)

It was considered that the three RDF data types, Bag, Alt and Seq, could substitute for logical constructions such as AND and OR.

  • Rather than allowing multiple bags with the same qualifier, it is better to make use of the rdf:Alt rather than rdf:Bag, which provides this "alternative" semantics
  • If we introduce rdf:Alt, we will need nesting of bags/alts, such that we can say an rdf:alt is composed of (rdf:Bag containing URI1 and URI2) or URI3.
  • rdf:seq - why would we want to use it? No.
    • Reasons against: Order does not imply importance. Sequence shouldn't be equated with ranking: it's overloading the semantics of "sequence". Also, sequence is qualitative, and some people may want to have quantitative ranking. Further, having two things in rdf:seq (like rdf:bag) implies that all of the listed items are "AND"-ed. A rdf:alt is an XOR and is what you want to use. You can order the items in the alt list, and this may provide what you need.

Goksel's interpretation of using qualifiers to create AND and OR with multiple qualifiers.

 <rdf:RDF xmlns:bqbiol="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
   <rdf:Description rdf:about="#metaid_0000008">
     <bqbiol:hasVersion>
       <rdf:Bag>
         <rdf:li rdf:ID="version1" rdf:resource="urn:miriam:Kegg:KeggMainID"/>
         <rdf:li rdf:ID="version2" rdf:resource= "urn:miriam:Chebi:ChebiMainID"/>
       </rdf:Bag>
     </bqbiol:hasVersion>
   </rdf:Description>
   <rdf:Description rdf:about="#version1">
     <bqbiol:hasPart>
       <rdf:Bag>
         <rdf:li rdf:resource="urn:miriam:Chebi:Chebi1"/>
         <rdf:li rdf:resource="urn:miriam:Chebi:Chebi2"/>
       </rdf:Bag>
     </bqbiol:hasPart>
   </rdf:Description>
   <rdf:Description rdf:about="#version2">
     <bqbiol:isHomologTo>
       <rdf:Bag>
         <rdf:li rdf:resource="urn:miriam:Kegg:Kegg1"/>
         <rdf:li rdf:resource="urn:miriam:Kegg:Kegg2"/>
       </rdf:Bag>
     </bqbiol:isHomologTo>
   </rdf:Description>
 </rdf:RDF>


Solution

  • We have bags(Containers) and we have Collections. How do we know whether annotations within these are ANDs or XORs?
    • We know if it's an AND or an XOR based on which qualifier is using the bag or collection. If you're using bqbiol:is, the bags nested independently within it define the element completely.
    • There must be an addition to the "use of qualifiers" page to specify whether the qualifier means that annotations within Containers or Collections within are XORs or AND.
    • We have not said anything about multiple bags within one qualifier, although the example we used implies that they may not be necessary
    • According to Allyson's definition, a Bag or Collection is only a convenience method to describe a set of triples without describing the relationships between them. Essentially each element of the Bag should be considered as an independent triple with the subject and predicate. To use maths, A * (X + Y) is the same as AX + AY.

Here are some snapshots of some examples that arose during discussion:





Possible new RDF-style tags for OR, XOR, NOT discussion

Short discussion on implicit semantics (above) and why we think it will not be sufficient.

  • listing of all (logical) interpretations necessary for every bqbiol (implicit semantics)
  • Currently, the solution says qualifier are either AND or XOR. To define fully combined expressions, we need at least 3 qualifiers (definition boolsche algebra, basic operations)!
  • We are not sure how you would like to express the NOT in your notation.

Example 1: NOT

<rdf:Description rdf:about="#Species_P">
 <NOT> 
  <bqbiol:isVersionOf>
    <rdf:Bag>
      <rdf:li rdf:resource="urn:phosphorylated:complex"/>
    </rdf:Bag>
  </bqbiol:is>
 </NOT>
</rdf:Description>

Example 2: OR vs. XOR

xor:


<rdf:Description rdf:about="#Species_P">
 <OR> 
  <bqbiol:hasPart>
   <rdf:Bag>
     <rdf:li rdf:resource="urn:something:A"/>
   </rdf:Bag>
  </bqbiol:hasPart>
  <bqbiol:hasPart>
   <rdf:Bag>
    <rdf:li rdf:resource="urn:something:B"/>
   </rdf:Bag>
  </bqbiol:hasPart>
 </OR>
</rdf:Description>


or:

<rdf:Description rdf:about="#Species_P">
 <XOR> 
  <bqbiol:hasPart>
   <rdf:Bag>
     <rdf:li rdf:resource="urn:something:A"/>
   </rdf:Bag>
  </bqbiol:hasPart>
  <bqbiol:hasPart>
   <rdf:Bag>
     <rdf:li rdf:resource="urn:something:B"/>
   </rdf:Bag>
  </bqbiol:hasPart>
 </XOR>
</rdf:Description>

Example 3: AND

<rdf:Description rdf:about="#Species_P">
 <AND> 
  <bqbiol:isVersionOf>
   <rdf:Bag>
     <rdf:li rdf:resource="urn:something:A"/>
   </rdf:Bag>
  </bqbiol:isVersionOf>
  <bqbiol:isVersionOf>
   <rdf:Bag>
     <rdf:li rdf:resource="urn:something:B"/>
   </rdf:Bag>
  </bqbiol:isVerionOf>
 </AND>
</rdf:Description>


Other examples

<rdf:Description rdf:about="#metaid_0000008">
   <bqbiol:is>
     <AND parseType=collection>
        <rdf:li rdf:resource="urn:URI1"/>
        <XOR>
          <rdf:li rdf:resource="urn:URI5"/>
          <rdf:li rdf:resource="urn:URI6"/>
        </XOR>
        <OR>
          <rdf:li rdf:resource="urn:URI8"/>
          <rdf:li rdf:resource="urn:URI9"/>
        </OR>
      </AND>
    </dbqbiol:is>
 </rdf:Description>


<rdf:Description rdf:about="#metaid_0000008">
  <AND>   
    <bqbiol:hasPart>
      <XOR>
        <bqbiol:isVersionOf>
          <rdf:li rdf:resource="urn:URI1"/>
        </bqbiol:isVersionOf>
        <bqbiol:isVersionOf>
          <rdf:li rdf:resource="urn:URI2"/>
        </bqbiol:isVersionOf>
      </XOR>
    </bqbiol:hasPart>
    <bqbiol:hasPart>
      <rdf:li rdf:resource="urn:URI3"/>
    </bqbiol:hasPart>
  </AND>
</rdf:Description>


"species is P1 and (P2 XOR P3) but not P4"

<rdf:Description rdf:about="#metaid_0000008">
  <bqbiol:hasPart>
    <AND>
      <rdf:li rdf:resource="urn:URI0"/>
      <XOR>
        <bqbiol:is>
          <rdf:li rdf:resource="urn:URI1"/>
        </bqbiol:is>
        <bqbiol:is>
           <rdf:li rdf:resource="urn:URI2"/>
        </bqbiol:is>
      </XOR>
      <NOT>
        <rdf:li rdf:resource="urn:URI2"
      </NOT>
    </AND> 
  </bqbiol:hasPart>
</rdf:Description>


What we propose instead

Using AND OR NOT XOR directly as element names appears to us less error prone than having implicit semantics of qualifiers defined at some external resource.

  • use of boolean operators AND OR XOR NOT
  • it is intuitive for tools exporting the annotations (e.g. that just need to read out and interpret the annotations, but do not see annotation as their main work.)
  • it is less error prone
  • test on similarity of expressions easily possible (methods to compare boolean expressions)



XML Types should be NOUNS discussion

Sorry to keep banging on about this but I'm convinced that the "type" of the description (the predicate) should be a noun.

EVERY example in the RDF Primer reads:

SUBJECT has PREDICATE whose value is OBJECT

I take the following xml to read that:

0001 has Part whose value is Y
0001 has Part whose value is X
X has Part whose value is { X1 | Q }
Q has Part whose value is X2
Q has Part whose value is X3

 <species metaid="0001"/>
   <rdf:Description rdf:about="#0001">
     <bqbiol:Part>
       <rdf:Bag>
         <rdf:li rdf:ID="Y"/>
         <rdf:li rdf:ID="X"/>
       </rdf:Bag>
     </bqbiol:Part>
   </rdf:Description>
   <rdf:Description rdf:about="#X">
   <bqbiol:Part>
     <rdf:Alt>
       <rdf:li rdf:ID="X1"/>
       <rdf:li rdf:ID="Q"/>
     </rdf:Alt>
   </bqbiol:Part>
   </rdf:Description>
   <rdf:Description rdf:about="#Q">
   <bqbiol:Part>
     <rdf:Bag>
       <rdf:li rdf:ID="X2"/>
       <rdf:li rdf:ID="X3"/>
     </rdf:Bag>
   </bqbiol:Part>
   </rdf:Description>
   <rdf:Description rdf:about="#X2">
   <bqbiol:Function>
     <rdf:Bag>
       <rdf:li rdf:resource="urn.miriam.functions.kinase"/>
     </rdf:Bag>
   </bqbiol:Function>
   </rdf:Description>
   <rdf:Description rdf:about="#X2">
   <bqbiol:PhosphorylationSite  rdf:parseType="Collection">
       <rdf:Description rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/>
   </bqbiol:PhosphorylationSite>
   </rdf:Description>
 </species>

The qualifier is always "has". We're currently attempting to hijack this by putting concepts of AND and OR into the predicate.

The predicate is a property of object, like address, colour, molecular weight, etc.

Which means that we misuse collections, as we're attempting to put the meaning of those collections into the predicate. RDF doesn't allow us to specify qualifiers. RDF specifies predicates (properties of the object).

The rest of the world uses Alt to imply OR. I don't know we don't...?

As we're defining properties (not qualifiers!) we can allow objects to have PhosphorylationSites. The final Description about X2 uses the RDF:nil term, and specifies...

X2 has PhosphorylationSite whose value is [EMPTY_SET]

...essentially a NOT.



Final solution for the time being (NLN: Epiphany)

After discussing and comparing the above, it seems we found agreement.

  • We will not use the names of the boolean operators as this does not seem to be proper RDF.
  • Instead, bqbiol:hasVersion, renamed to bqbiol:Version, will be used in a logic sense as an OR. Indeed, versions are non-exclusive alternatives. If we have two statements "X has version A", and "X has version B", X can be A OR B OR A and B.
  • Furthermore, bqbiol:is (identity?) will be used in a logic sense as an AND. Indeed, if we have two statement "X is A" and "X is B", X must be A AND B.
  • We will have to define the meaning of Version and identity in the annot-spec. That is, there will be the definition of the qualifier as well as the logical interpretation of it.
  • We currently do not have a solution for NOT, but we anticipate something like bqbiol:isNot.
  • We currently do not have a solution for XOR, or do we? Ron: once we have NOT all other operators like XOR, NAND can be derived.
  • We only use bag and collections for "identity" and "version". A list of identities are all valid (AND) while a list of versions are alternatives(OR). For all the other qualifications, we use ONE qualification for ONE resource. Effectively that means: Only one li element is allowed per rdf:description.
  • The advantage is: We can mix and match as much as we want.

Example

The following example is simple: only one level of depth, and no hybrid lists. We can do better. NLN: I complexified the example for fun

SARAH: We need to think about the relationship between 'identity' and 'version'. The example below says

  1. species0001 has identity A AND B AND C
  2. species0001 has versions P OR Q

Is it 1 AND 2; 1 OR 2 ?????

I assume it is AND as that seems most in line with the current annotations !

NLN: Should we have only one top element? If the combination is AND, we could basically include the bqbiol:version IN the bqbiol:identity, as I did for the parts X and Y. We would get:

"species 001 is [A and B and C and (P or a complex of X and Y)]"

<species metaid="0001"/>
  <rdf:Description rdf:about="#0001">
    <bqbiol:identity>
      <rdf:Bag>
        <rdf:li>
          <rdf:Description rdf:ID="A"/>
        </rdf:li>
        <rdf:li>
          <rdf:Description rdf:ID="B"/>
        </rdf:li>
        <rdf:li>
          <rdf:Description rdf:ID="C"/>         
        </rdf:li>
      </rdf:Bag>
    </bqbiol:identity>
    <bqbiol:version rdf:parseType="Collection">
      <rdf:Description rdf:ID="P"/>
      <rdf:Description rdf:ID="Q"/>         
    </bqbiol:version>     
  </rdf:Description>
  <rdf:Description rdf:about="A">
   <bqbiol:homolog rdf:resource="miriam:A" />
  </rdf:Description>
  <rdf:Description rdf:about="B">
   <bqbiol:homolog rdf:resource="miriam:B" />
  </rdf:Description>
  <rdf:Description rdf:about="C">
   <bqbiol:homolog  rdf:resource="miriam:C" />
  </rdf:Description>
  <rdf:Description rdf:about="P">
   <bqbiol:identity rdf:resource="miriam:P" />
  </rdf:Description>
  <rdf:Description rdf:about="Q">
    <bqbiol:part>
       <rdf:Bag>
         <rdf:li rdf:resource="X" />
         <rdf:li rdf:resource="Y" />
       </rdf:Bag>
    </bqbiol:part>
  </rdf:Description>
</species>


SARAH: I changed this from the original as you cannot have an li element that is not in a container/collection. Also the bag containing the descriptions must have li elements Image:icon_smile.gif.

NLN: I changed "bqbiol:description" to "bqbiol:identity".

WOLF: A slight modification (which to my impression makes things more aesthetic): We use the above concept, but instead of "identity" and "version", we use three new qualifiers "canBe", "isDefinitely" and "isNot". They just mean what their names say. Whenever there are several statements (either in different rdf descriptions of collected in a bag), they are always understood to be combined by an AND. Effectively, combinations of such statements will automatically work like boolean OR, AND, and NOT, respectively

What we want to say in the above example is

  each instance (=molecule) of species0001 is an A
  AND each instance (=molecule) of species0001 is a B 
  AND each instance (=molecule) of species0001 is a C
  AND some instances (=molecules) of species0001 are Ps 
  AND some instances (=molecules) of species0001 are Qs 

this would be rephrased as

  species0001 isDefinitely A
  AND species0001 isDefinitely B)
  AND species0001 isDefinitely C
  AND species0001 canBe P
  AND species0001 canBe Q

or, in short (where logical ANDs everywhere are understood)

  species0001 isDefinitely {A,B,C}
  species0001 canBe {P,Q}

which translates directly into RDF

"isNot" for the logical NOT could be treated just the same way.

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

This page was last modified 12:11, 17 June 2010.



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