Menu

#147 Semantic rule "EPN must have an arc" is wrong

PD
open
nobody
5
2013-03-17
2012-08-28
No

The current version L1 V1.3 of the PD specification says in 3.5.1
"3. EPNs should not be orphaned (i.e. they must be associated with at least one
arc." I would read this as "EPNs must have an arc".

In a SBML model a species can be defined which is not part of a reaction.
If I want to visualize this SBML model in SBGN PD (most likely as EPN) I would have to remove this species to get a valid PD map because of the rule mentioned above.

Thus I think rule 3 of 3.5.1 is wrong and should be removed from the spec.

Discussion

  • Nicolas Le Novère

    I agree that this rule should be removed. It is unecessary, and unenforcable.

     
    • Stuart Moodie

      Stuart Moodie - 2013-03-17

      It is easily enforceable. Node_degree == 0 is an error. We agreed a rule in Okinawa that all Sink/Source nodes would have a degree 1. This is where this rule originated. I think you can make a strong argument for it, it is really a question of whether you want to ensure as much as you can that all SBGN maps are sensible. Certainly it would make sense to be a warning at least.

       
  • Stuart Moodie

    Stuart Moodie - 2013-03-17

    Hmmm. It does seem overly strict but what does an EPN with no connections mean. No process is being described. I expect that in all cases someone drawing an orphaned EPN would be a mistake. Certainly is makes no sense with an Empty Set. I'm not sure what the best course of action is. It does make sense as a warning, but perhaps it is overly strict. Perhaps we could recommended this as a warning.

     
  • Nicolas Le Novère

    There are several points that bother me here.

    1) Why is an orphaned EPN a problem? It does not cause the map to be ambiguous. There is an EPN. We know it exists. We represent it. Why is it a problem at all? " what does an EPN with no connections mean?". It means an EPN, that's it.

    2) The design of an SBGN map is a lengthy process. As with the design of any model, or any systems biology activity, we start by listing the parts and then go on building up relationships. Banning that means any intermediate maps would be invalid. A few years ago, we bumped into a similar problem with SBML. When we developed the first version of SBML editor, we could not use it at all. Because whatever we would do resulted in an invalid model.

    3) Many sources of SBGN maps are cluttered with unlinked EPNs. Think about KEGG pathways. There is generally a reference pathway, where most EPNs are linked. And then there are all the species specific pathways, where many EPNs are missing, resulting in even more processes missing, finally resulting in plenty of "orphaned" EPNs.

    Point 1 is the most important here. It is a concern that I will carry throughout my comments on many tickets here. We assume there is a "correct" way of doing things, and we want to force everyone to do it that way. But first there is not such a thing as a correct way of doing thing. As for myself, many things I considered the correct way 2 years ago are completely the opposite of what I am doing now (now that I moved from a date resource developer to a data generator). Second, There is no way we can force people to do thing our way. As I said many times "a standard is used when it is easier to use it than not to use it". This kind of rule

     
MongoDB Logo MongoDB