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

SEP V014: Modules and MapsTo #48

Closed
jakebeal opened this Issue May 21, 2018 · 13 comments

Comments

Projects
None yet
4 participants
@jakebeal
Copy link
Contributor

jakebeal commented May 21, 2018

The ModuleDefinition, Module, and MapsTo classes from SBOL 2 do not yet have an equivalent representation in SBOL Visual.

@jakebeal jakebeal added this to the SBOL Visual 2.1 milestone Jun 20, 2018

@cjmyers cjmyers changed the title Modules and MapsTo SEP V014: Modules and MapsTo Jun 23, 2018

@jamesscottbrown

This comment has been minimized.

Copy link
Contributor

jamesscottbrown commented Jul 19, 2018

@jamesscottbrown

This comment has been minimized.

Copy link
Contributor

jamesscottbrown commented Jul 20, 2018

After a discussion of a draft diagram, I have a couple of suggested additions:

  • Insert "A port MUST NOT be connected to more than one glyph outside of the module, unless all of the glyphs it connects to represent the same entity"

  • After "It is RECOMMENDED that a black-box module be drawn with ports, as if a line or arrow crosses the boundary of the module at a position other than a port it is impossible to see where it terminates.", insert "If a line or arrow crosses a module's boundary other than at a port, it SHOULD be labelled."

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Jul 20, 2018

@jamesscottbrown Can you please edit these into the draft SEP?

jakebeal added a commit that referenced this issue Jul 20, 2018

Merge pull request #53 from SynBioDex/SEP-V014
two additions to SEP_V014 (#48)
@JS3xton

This comment has been minimized.

Copy link

JS3xton commented Jul 20, 2018

Can you link to concrete definitions for Modules and the MapsTo relation? (sorry for being lazy and not digging it up myself)

How does the MapsTo relation relate to the Interaction Glyphs? (specifically, how is the MapsTo relation different than the Process Interaction Glyph?)

I also prefer not constraining the line style if possible (i.e. I don't like the idea of REQUIRING MapsTo lines to be dashed lines).

@cjmyers

This comment has been minimized.

Copy link

cjmyers commented Jul 21, 2018

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Oct 5, 2018

I've read through carefully, and am satisfied to see this move forward to a vote.

@jakebeal jakebeal added the SEP label Oct 9, 2018

@JS3xton

This comment has been minimized.

Copy link

JS3xton commented Oct 11, 2018

Some organizational suggestions for the current SEP:

  • It might be helpful break out the specification of MapsTo (paragraphs 4-6 under the "2. Specification" heading) into a separate subsection (e.g. "Representation of MapsTo").
  • It might be helpful to package the specification of "ports" into their own subsection or subsubsection.
  • It might be helpful to package the special rules for "black-box" modules into their own subsection.
  • It's unclear to me if: "If a line or arrow crosses a module's boundary other than at a port, it SHOULD be labelled." refers to all modules or just black-box modules.

Other comments:

  • I don't know if I endorse RECOMMENDING ports on black-box modules.

  • I want to amend my previous position on dashed lines for MapsTo (I was previously against RECOMMENDING them): I think they look pretty clean and work well in the left example.

  • The following specification of MapsTo is confusing and seems to overload the Process Interaction Glyph:

    A MapsTo relation MAY be indicated by a line with no arrowhead; alternatively, to visually distinguish between inputs and outputs of a module, a MapsTo relation for the input of a module MAY be drawn with a filled arrowhead directed into the module, and a MapsTo relation for the output of a module MAY be drawn with a filled arrowhead directed out of the module.

    As an alternative to depicting MapsTo relations, it is permitted to draw arrows entering a module. In such a case, the representation of the module does not modify the semantics of the interactions shown: it simply indicates that where the corresponding interaction is defined.

    Here are all the ways I can think of to draw SBOL Visual arrows relative to a module boundary:

    arrow_module

    • A MapsTo relation MAY be indicated by a line with no arrowhead (1,7,13,19)
    • a MapsTo relation for the input of a module MAY be drawn with a filled arrowhead directed into the module (2,8. Overloads Process Interaction Glyph)
    • a MapsTo relation for the output of a module MAY be drawn with a filled arrowhead directed out of the module (14,20. Overloads Process Interaction Glyph)
    • (*)As an alternative to depicting MapsTo relations, it is permitted to draw arrows entering a module. In such a case, the representation of the module does not modify the semantics of the interactions shown: it simply indicates that where the corresponding interaction is defined. - I don't understand what this means.
    • Everything else, by default, MUST be an Interaction Glyph? (and thus not a MapsTo). It's unclear how those interactions are modified by the module, though (one would hope intuitively, i.e. the interaction sources and sinks exist inside or outside of the module as appropriate). Perhaps this is what (*) was trying to get at.

    I'm also actually fine with overloading the Process Glyph, I just think it needs to be clearly specified.

  • I think the mention of ModuleDefinition (which is an SBOL concept) at the end of the "2. Specification" section should be replaced with "module" (which we are defining here as an SBOL Visual concept).

  • On the left example, are the arrows from cas9_generic and gRNA_generic to cas9_gRNA_complex MapsTo arrows? (I don't think they should be, but they're dotted lines, which is a little confusing):

    image

  • On the right example, the arrow colors are a little confusing for me. I assume it's supposed to indicate Interactions that take place inside the module? At first I thought it was simply the "distinguishing feature" that differentiated Process Interaction Glyphs from MapsTo glyphs, but upon studying the diagram, the Process Interaction Glyphs are both black and purple whereas the MapsTo glyphs are purple. (Unrelated: the stimulation glyph is also used across a module boundary, which, as noted above, is arguably not well defined).

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Oct 11, 2018

There are some good catches there, John.

It's unclear to me if: "If a line or arrow crosses a module's boundary other than at a port, it SHOULD be labelled." refers to all modules or just black-box modules.

Re-reading this, I am unclear as well, particularly because this isn't shown in any of our examples (and they seem to be clear). I think this sentence should either be embodied in examples or else removed.

I don't know if I endorse RECOMMENDING ports on black-box modules.

I can see it either way: I think it would be good to have "RECOMMENDED" vs. "OPTIONAL" be a choice in the adoption vote.

On process glyph overloading:

a MapsTo relation for the (input/output) of a module MAY be drawn with a filled arrowhead directed into the module

Looking at our examples, it seems that we only draw arrows if we're showing the MapsTo+interaction combined, rather than showing the MapsTo separately. Thus, I think it makes sense to either remove this overloading option or else add examples that really need it.

On the left example, are the arrows from cas9_generic and gRNA_generic to cas9_gRNA_complex MapsTo arrows?

These are showing an interaction, and thus should be solid --- and also should probably be replaced with an association multi-tail arrow per SEP V013, since that looks likely to be adopted.

@JS3xton

This comment has been minimized.

Copy link

JS3xton commented Oct 11, 2018

On process glyph overloading:

a MapsTo relation for the (input/output) of a module MAY be drawn with a filled arrowhead directed into the module

Looking at our examples, it seems that we only draw arrows if we're showing the MapsTo+interaction combined, rather than showing the MapsTo separately. Thus, I think it makes sense to either remove this overloading option or else add examples that really need it.

When I mentioned "overloading", I suppose I meant that an arrow could be either a MapsTo or an Interaction glyph, and which one it is would be based on context. You seem to be proposing that an arrow could be both a MapsTo and an Interaction glyph. This makes a lot of sense to me. Again, I would encourage that we specify it concretely, though. Perhaps: "any Interaction Glyph that crosses a module boundary implies an unillustrated MapsTo glyph". Some examples:

arrow_module2

This use case is embodied by the black solid-head arrows in the Right Example (are those Process glyphs? MapsTo glyphs? Both?).

It follows that to specify only the MapsTo relationship, you'd have to use NOT an Interaction Glyph (i.e. a no-head arrow? With a RECOMMENDED line style of dashed?).

Also, how do modules relate to membranes (i.e. "physical" modules)? Can membranes simply be classified as modules? There are additional membrane details (e.g. proximity to and structure of) that may not hold generally for modules.

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Oct 11, 2018

@JS3xton I agree with your interpretation and examples regarding MapsTo.

With respect to membranes: currently, the specification is silent on this question. I think in many cases they would make sense to specify as modules, but would suggest deferring a careful consideration of them for later.

@cjmyers

This comment has been minimized.

Copy link

cjmyers commented Oct 11, 2018

In SBML, membranes are handled separately from modules. Namely, membranes are represented as compartments while modules are subModels. I agree with Jake that we have not settled this one, and I can see a point for not conflating physical boundaries with simply hierarchical representation of a design.

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Nov 4, 2018

Based on these conversations, I have prepared an updated version of SEP V013, along with draft changes to the spec. The pull request containing the full diffs is here: #56

The updated SEP V014 in particular may be found here: https://github.com/SynBioDex/SBOL-visual/blob/c0445cf/SEPs/SEP_V014.md

@jakebeal jakebeal added the Accepted label Nov 25, 2018

@jakebeal

This comment has been minimized.

Copy link
Contributor Author

jakebeal commented Jan 25, 2019

Accepted and integrated, and thus closed per SBOL procedure in updated SEP 001.

@jakebeal jakebeal closed this Jan 25, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.