SEP V006: No Glyph Assigned

[Jake Beal]

As we have deferred No Glyph Assigned out of SEP V003, I have now created SEP V006, which contains my best understanding of the current state of options. The SEP is here: https://github.com/SynBioDex/SBOLv-realizations/issues/11

In essence, the current proposal is:

- When a part has no assigned glyph it is RECOMMENDED that a user provide their own glyph. The user is also encouraged to submit the new glyph for possible adoption into the SBOLv standard.

- As a fallback alternative (and support for machine rendering), either:

  - We use dashed rectangles, enforcing that dashes cannot be used elsewhere.

  - We *remove* rectangle as an allowed glyph for Composite, so that Composite can use it only as a base glyph (for No Glyph Assigned) with a secondary backbone, e.g.,

 
​

  - We come up with some other alternative

For the alternatives, I personally like the second option best, as it provides clear distinctions without mandating styling.

Let us discuss.

Thanks,

-Jake

[Chris Myers]

Hi Jake,

An important point that is missed in this proposal is that I believe that we should have a glyph for Engineered Region (http://www.sequenceontology.org/browser/current_svn/term/SO:0000804).  Note this is not the same as a composite.  A composite is defined as any CD that has substructure regardless of the role assigned to that CD.  Furthermore, an Engineered Region is not required to even be a composite.  It does not need to have assigned substructure.  It could be abstract with a yet to be defined structure of any kind.

My vote remains that rectangle should be the glyph for Engineered Region. 

As fro No Glyph Assigned, my vote would be that any glyph can be used which is not already a RECOMMENDED glyph for another SO term.  In other words, No Glyph Assigned would be explicitly forbidden to be a rectangle, since Engineered Region SO term would have that.  

As for guidance to a developer of software for machine rendering, we could select a shape (not rectangle with solid borders) and suggest that shape have the role written above/below/inside it.  Frankly, the boxes that are cluttering our diagrams in machine rendered visualizations of GenBank converted files make the diagrams not very nice to look at, and also not very informative.

Cheers,

Chris

On Sep 14, 2017, at 4:55 AM, Jake Beal <jake...@gmail.com> wrote:

As we have deferred No Glyph Assigned out of SEP V003, I have now created SEP V006, which contains my best understanding of the current state of options. The SEP is here: https://github.com/SynBioDex/SBOLv-realizations/issues/11

In essence, the current proposal is:

- When a part has no assigned glyph it is RECOMMENDED that a user provide their own glyph. The user is also encouraged to submit the new glyph for possible adoption into the SBOLv standard.

- As a fallback alternative (and support for machine rendering), either:

  - We use dashed rectangles, enforcing that dashes cannot be used elsewhere.

  - We *remove* rectangle as an allowed glyph for Composite, so that Composite can use it only as a base glyph (for No Glyph Assigned) with a secondary backbone, e.g.,

 <abbreviated-composite-example2.png>
​

  - We come up with some other alternative

For the alternatives, I personally like the second option best, as it provides clear distinctions without mandating styling.

Let us discuss.

Thanks,

-Jake

--
You received this message because you are subscribed to the Google Groups "SBOL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sbol-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jake Beal]

Hi, Chris:

I could certainly support *removing* the Engineered Region SO term from Composite and defining it to instead be a non-SO "anything with defined sub-components."  That would be entirely consistent with how it is being used, and would complement Omitted Detail nicely.

What I would like to understand better is this: what you are aiming to represent with "Engineered Region"?

My current understanding is that Engineered Region is essentially serving as a catch-all for "this has been explicitly identified as not having any better category" --- as distinct from Sequence Feature, which is indicating "this sequence has not been identified." If this is the case, then I would suggest that we don't actually need to have a specific glyph for Engineered Region, and should instead have it represented by No Glyph Assigned --- which could then use the rectangle.  If that's problematic because of clutter in GenBank conversions, that's what the "thin rectangle" styling suggestion is intended to alleviate.

Thanks,

-Jake

[Chris Myers]

Hi Jake,

We use Engineered Region to represent Composites such as an RBS/CDS or a Prom/RBS/CDS/Term, etc.  Basically, they are groups of objects organized hierarchically.  This is different though than the general idea of Composite which includes things like a double terminator that is well represented with a terminator glyph.  Therefore, I want a glyph that says, “Click on me to find out what is inside” that is different from a glyph that says “This object has a role but sadly I don’t have a nice way to render it”.

I cannot stress enough that I strongly object to rectangle to mean, I don’t know how to render this.  I think this is completely inconsistent with other types of hierarchical diagrams where the box represents a hierarchal entity.  

If we drop the “alternative styling” term and make thin rectangle the RECOMMEND glyph for No Glyph Assigned, and the original rectangle Engineered Region, I could live with that.  Note aspect ratio should not be styling, in my opinion.  It is part of the definition.  At a minimum, I should be able to have three glyphs with four sides.  Namely, one where width > height (Engineered Region), height > width (No Glyph Assigned), and height=width (currently operator, and likely will remain as an alternative glyph for this even if we change it, since it is so commonly used).

Cheers,

Chris

[Jake Beal]

Hi, Chris:

I think I'm getting a clearer understanding of your goal here. 

I am still confused about one thing: 

- in your last email, you said: Engineered Regions "are groups of objects organized hierarchically."

- in your prior email, you said: "an Engineered Region is not required to even be a composite"

These two seem to me to be in conflict --- if we have something that invites people to click inside, but they aren't actually composites, isn't that frustrating the goal you're aiming for?

Thanks,

-Jake

[Chris Myers]

Hi Jake,

Let me see if I can illustrate this with a use case from SBOLDesigner.  Assume you are building a GeneticToggleSwitch.  If I’m doing top down design, I might start out by instantiating two Engineered Regions as shown below.  Currently, these do not have sub-structure, though certainly they are intended to eventually have sub-structure.  So, if I were to stop here to have a coffee, this would be a fine rendering of two Engineered Regions which are not composites.  Later, I may come back and fill in the details for these genetic inverters.  At this point, they are composites.  We could put two little dashes now above/below the boxes (consistent with Composite dashed lines approved now) to indicate that these Engineered Regions are now composites.

Now, consider again looking at my attached diagram with the idea that rectangle is No Assigned Glyph (including Engineered Region).  If this is the case, I don’t know if this is two sequence features which I don’t know how to render OR two Engineered Regions that I have not yet filled in the details for.  These are VERY different things, and I would like them to be rendered differently.

This entire discussion started because when Michael and I were considering which SO terms to use for this Glyph, we realized that while we were thinking that these were Engineered Regions and should use that SO term for this Glyph, we realized that was not what the specification says, that it could indeed represent any SO term with no glyph.  This is very problematic for the UI as the default sort of SO terms provided as choices to the user for role refinement on these glyphs is very different depending on whether it should be Engineered Region and all it children OR Sequence Feature and all its children (over 2800 choices!!!).  

Hope this clarifies the problem this issue is causing our development.

Thanks,

Chris

[Jake Beal]

Hi, Chris:

Thank you for your patients and for a use case explanation that I found very clear. I think I understand the problem well now, as well as your reluctance to give up rectangle for No Assigned Glyph.

As such, I'd like to put forward an alternate possibility for No Assigned Glyph: I'm thinking it might be well represented by brackets. My preference would be square brackets "[ ]", but it could also be angle "< >" or curly "{ }" or maybe even parentheses "( )".

We could also give a suggestion that the name of the thing represented by the glyphj be put into those brackets, e.g., "[transposon]"

I like the idea of brackets because:

- They capture the idea of "additional information gets filled in here"

- They are very simple

- We aren't using them for anything else (they were considered for a couple of things, but not selected)

What do you think?

Thanks,

-Jake

[Chris Myers]

Hi Jake,

Thanks also for your patience in reading through all these explanations.
  

I like your brackets proposal very much.  It is much more descriptive than a box.  It is also not that pleasant, so the more it is seen, the more people will want to replace it with a glyph.  :-)  

Cheers,

Chris

[Jake Beal]

I have now updated the SEP to include the brackets glyph as the current preferred alternative, based on this discussion.

Thanks,

-Jake

[Anil Wipat]

Sorry, I'm late to the conversation. I also agree that the brackets are a good idea though I would urge developers of visualisation systems to include options to customise which glyphs are shown. Complicated visualisations with unfamiliar symbols will be off putting to many.

Best

Neil

Sent from my iPhone