Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simmap vocabulary issues: char and stateChange #108

Open
hlapp opened this issue Jan 2, 2015 · 3 comments
Open

simmap vocabulary issues: char and stateChange #108

hlapp opened this issue Jan 2, 2015 · 3 comments

Comments

@hlapp
Copy link
Contributor

hlapp commented Jan 2, 2015

The following is the simmap example in the current manuscript draft:

 m <- meta("simmap:reconstructions", children = c(
        meta("simmap:reconstruction", children = c(

          meta("simmap:char", "cr1"),
          meta("simmap:stateChange", children = c(
            meta("simmap:order", 1),
            meta("simmap:length", "0.2030"),
            meta("simmap:state", "s2"))),

          meta("simmap:char", "cr1"),
          meta("simmap:stateChange", children = c(
            meta("simmap:order", 2),
            meta("simmap:length", "0.0022"),
            meta("simmap:state", "s1")))
          ))))

Questions:

  1. Why do we need to have two simmap:char properties? Is it really possible that a branch can change state from one state of one character to a state of a different character? And even if that were possible, shouldn't the simmap:char then instead be a property of simmap:stateChange?
  2. I am assuming that the reason we have to have a simmap:char to start with is because a NeXML state object may (in theory) be reused between different characters, and so which character we are talking about needs to be stated explicitly rather than letting it be determined implicitly?
  3. Is there a reason the simmap:stateChange element is named that way? It sounds odd that a state change has a length (the status of being in a certain state may have a length, but the change to a state?), and if indeed what is being described is a state change, I would expect to see something like fromState and toState as properties. Is stateChange perhaps a misnomer?
@hlapp
Copy link
Contributor Author

hlapp commented Sep 22, 2015

I don't think we've addressed this for the manuscript (and it's more a general modeling improvement issue, I would say), and so I'm de-coupling this from the manuscript milestone again.

@cboettig
Copy link
Member

👍

@cboettig
Copy link
Member

All good points here. Just for the record, here's how we originally decided on what we have here

#48

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants