API documentation

[mwatts15]

• Method signatures
• javadoc comments

[mwatts15]

A flavor of the developing API: http://my-openworm-docs.readthedocs.org/en/latest/api.html

[slarson]

Looking nice!

[DickGordonCan]

Dear Mark,
In:

---

Example:

v = Quantity("600","um")
c = Cell(lineageName="AB plapaaaap")
c.divisionVolume(v)

---

"um" should be "(µm)^3". Thanks.
Yours, -Dick Gordon

[VahidGh]

Looking good...
Assuming we will need to support more biological networks (beside neural networks) in order to complete locomotion dynamics, we need to add muscle cell class (or other cell types). so, we could have a more general connection class like this:
Connection(pre: Cell, post:Cell,...)
and inherit other type of connections from this class.

[mwatts15]

We could generalize the signaling relationship to:

• a sending population
• a receiving population
• the thing sent

On Mon, Jun 2, 2014 at 5:27 AM, Vahid Ghayoomi notifications@github.com
wrote:

Looking good...
Assuming we will need to support more biological networks (beside neural
networks) in order to complete locomotion dynamics, we need to add muscle
cell class (or other cell types). so, we could have a more general
connection class like this:
Connection(pre: Cell, post:Cell,...)
and inherit other type of connections from this class.

—
Reply to this email directly or view it on GitHub
#4 (comment).

Cheers,
Mark Watts
Department of Computer Science
University of Texas at Austin

[slarson]

Based on some comments from today's discussion:

• Ability to add a DOI / PMID / WormBaseID to Evidence is important
• Example code should be as close as possible to code that could actually be written once the API is implemented
• Evidence class should insulate the user from complexities of BibTex even though BibTex is a great choice for the underlying data representation
• Let's think more about the utility of asserting a triple directly
• Make sure to clarify that a Relationship is a whole triple (not just a relation i.e. the middle of a triple)

[slarson]

More comments from today's discussion

• Let's see if the Quantity class can take in a string with units and parse it. Let's see if we can find a library that does that parsing for us rather than writing it ourselves (may not be the best use of our time)
• Let's define the Morphology class or drop it in favor of NeuroML Morphology
• Add in any additional setter methods that are currently implicit if we plan to have them for tracking purposes and so we can make the scope of the API finite.
• Let's flesh out the Relationship class and let's define the constructor. Specifically what types of objects will you be able to add to a Relationship? Any type?
• Let's also think about a general way to get Relationship objects that is easy to use and is tightly linked to the methods that get and set data on the major classes of the API

For now let's hold off on the Signaling class but we should save this and come back to it if we have time at the end:

Signaling(sender : Population, receiver : Population, messengerSpecies : Object )

Signaling.sender() : Population
++++++++++++++++++++++++++++++++

Signaling.receiver() : Population
++++++++++++++++++++++++++++++++++

Signaling.messengerSpecies() : Object
+++++++++++++++++++++++++++++++++++++

Signaling(p1,p2,"Glutamate") <-- behind the scenes Connection relationships get created and that means having a way to define if connections are all - to - all or random or some other connection pattern

Let's also leave the Simulation class out for now until we have time perhaps at the end.

[mwatts15]

I've started written some tests (af5c7ae) based on this one:
Ability to add a DOI / PMID / WormBaseID to Evidence is important

[mwatts15]

@slarson I have checked off items which I've addressed in the draft API (9fd57fa).
I'll be adding missing stubs and transferring the documentation to code.

[slarson]

@mwatts15 looking good!