{"action":"created","issue":{"url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/54","labels_url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/54/labels{/name}","comments_url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/54/comments","events_url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/54/events","html_url":"https://github.com/kroneckerbio/kroneckerbio/issues/54","id":106546126,"number":54,"title":"How to deal with duplicate species names","user":{"login":"drhagen","id":2952478,"avatar_url":"https://avatars.githubusercontent.com/u/2952478?v=3","gravatar_id":"","url":"https://api.github.com/users/drhagen","html_url":"https://github.com/drhagen","followers_url":"https://api.github.com/users/drhagen/followers","following_url":"https://api.github.com/users/drhagen/following{/other_user}","gists_url":"https://api.github.com/users/drhagen/gists{/gist_id}","starred_url":"https://api.github.com/users/drhagen/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/drhagen/subscriptions","organizations_url":"https://api.github.com/users/drhagen/orgs","repos_url":"https://api.github.com/users/drhagen/repos","events_url":"https://api.github.com/users/drhagen/events{/privacy}","received_events_url":"https://api.github.com/users/drhagen/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-09-15T12:37:25Z","updated_at":"2015-09-17T22:17:44Z","closed_at":null,"body":"Let's continue to break issues #44 and #47 done into smaller parts, as having omnibus issues is not conducive to discussion. Let me lay out the proposed designs for this so we have something concrete to discuss.\r\n\r\nLet's lay a few facts that I think everyone will agree with:\r\n* Most species do not have duplicate names. Designing for this as the common case is a good idea.\r\n* If a species name is not duplicated, it should be able to be referred by that name.\r\n\r\n1) \"No ambiguity\"\r\n* All species must have unique names `glucose` and `ecm_glucose` or `ecm.glucose`\r\n* Benefits: All species have exactly one name, and that name is the one the user provided. The user can give the short name to the most commonly used version.\r\n* Drawbacks: More typing when defining the species (i.e. in `AddState(m, 'ecm_glucose', 'ecm')`).\r\n\r\n2) \"Forced disambiguation\"\r\n* Species names may be duplicated. In reactions, duplicate species must be disambiguated with their compartment `cell.glucose`\r\n* Benefits: All species pretty much have one name, for unique names its the bare name and for duplicate names its the disambiguated version. Adding a new species with a duplicate name will throw an error rather than silently changing the behavior of the model. It does not interfere with models that don't have duplicate names.\r\n* Drawbacks: None of the duplicate members can be referred to by their short name.\r\n\r\n3) \"Disambiguate to first species\"\r\n* A bare species name \"glucose\" refers to the species that is listed first\r\n* Benefits: All species again pretty much have one name. It does not interfere with models that don't have duplicate names.\r\n* Drawbacks: Adding a duplicate species in front of another silently changes the behavior of the model; one also needs to choose whether inputs or states are first in this rule.\r\n\r\n4) \"Disambiguate to first compartment\"\r\n* A bare species name refers to the species that appears in the first compartment in which it is found\r\n* Benefits: Same as (3), plus we don't have to decide whether inputs are states are first.\r\n* Drawbacks: Like (3) adding a species that goes into an earlier compartment silently changes the model.\r\n\r\n5) \"Reaction compartments\"\r\n* Each reaction gets a compartment argument that is used to disambiguate the species. Multiple compartments may be listed and it looks only in that list for the names of the species, unless the list is empty, then it looks in all of them. Species may be directly disambiguated.\r\n* Benefits: This is how it is currently done. As many reactions happen within a compartment, this can disambiguate a few reactants and products at once.\r\n* Drawbacks: Every species now has two names. When you can use one of another is pretty complicated. Every function that accepts species names now has to gain a compartment argument to remain consistent with reactions. The reaction compartment argument must be supplied on every reaction (even if empty) in models that have no ambiguous names."},"comment":{"url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/comments/141253272","html_url":"https://github.com/kroneckerbio/kroneckerbio/issues/54#issuecomment-141253272","issue_url":"https://api.github.com/repos/kroneckerbio/kroneckerbio/issues/54","id":141253272,"user":{"login":"dflowers7","id":7842102,"avatar_url":"https://avatars.githubusercontent.com/u/7842102?v=3","gravatar_id":"","url":"https://api.github.com/users/dflowers7","html_url":"https://github.com/dflowers7","followers_url":"https://api.github.com/users/dflowers7/followers","following_url":"https://api.github.com/users/dflowers7/following{/other_user}","gists_url":"https://api.github.com/users/dflowers7/gists{/gist_id}","starred_url":"https://api.github.com/users/dflowers7/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dflowers7/subscriptions","organizations_url":"https://api.github.com/users/dflowers7/orgs","repos_url":"https://api.github.com/users/dflowers7/repos","events_url":"https://api.github.com/users/dflowers7/events{/privacy}","received_events_url":"https://api.github.com/users/dflowers7/received_events","type":"User","site_admin":false},"created_at":"2015-09-17T22:17:43Z","updated_at":"2015-09-17T22:17:43Z","body":"Here are my thoughts.\r\n\r\nThe problem with (2) is that, from the user's end, it is essentially the worst of all the options. While technically they can name different species the same thing, functionally they must use the full name everywhere in the model building code except for the addState or addInput call. In addition, the user now has no control over how to refer to those species, which was one of the advantages of (1) (I still am not a huge fan of (1), just to be clear, for the reason I am about to explain).\r\n\r\nThe advantage of the current framework, (5), the one that holds the highest priority for me, is that it is MUCH more amenable to programmatic model construction. If one has a large set of reactions, each of whose species all exist in one compartment, and those same reactions need to be added to multiple compartments, one can iterate over a list of the compartments, calling addReaction and only changing the reaction compartment argument.\r\n\r\nOn the other hand, solutions (1) and (2) require that the user do a bunch of string manipulation to generate the species names appropriate for each addReaction call. This isn't particularly annoying for the stoichiometry arguments, but it's incredibly annoying for the rate expressions. The user basically gets to play regular expression golf to try to do the string replacements correctly. In this case, all the complexity that we're hoping to avoid, plus the complexities we've already dealt with in trying to convert names in expressions to IDs, are thrust upon the user. (3) and (4) aren't much better in this regard because the user has no good way to override the default default compartment..\r\n\r\nIt seems that the primary source of complexity in (5) is in having two levels of defaults for compartments being added to reactions. We have a reaction-specific default behavior determined by the default compartment argument in addReaction and a model-wide default behavior that kicks in if no default is provided. I don't really care very much what the model-wide default behavior is, since any choice will only sometimes be useful. But I do care about reaction-specific defaults, for the reasons I just described. If we want to eliminate complexity, we can just avoid specifying any kind of model-wide default. I imagine this would look like a variant of (5), in which\r\n\r\n* the default compartment argument of addReaction is moved to the last argument (so that it can be left off if specifying it is undesired),\r\n* only one compartment can be given as a default, and\r\n* If a reaction default is not provided, species existing in multiple compartments must have compartments specified in their names.\r\n\r\nThis way, addReaction behaves exactly as it would in (2) if one leaves off the default compartment, but still conveys the benefits of (5) when they are useful."}}