Stylistic request: make types and tokens readily distinguishable

[rpgoldman]

In the SD2 program, we have SBOL genetic network models that have instances of guide RNAs (tokens), and what seem to be prototypical entities (types) as well, e.g., "r6 gRNA."

The types and tokens have typically been given the same name, and they seem to have the same string representation when used through pySBOL. This leads to bugs that can be quite difficult to find, since the python interaction is misleading.

Could we please establish a representational convention that gives these entities easily distinguishable representations in code? Maybe something like "r6 gRNA" and "r6 gRNA proto"? Even just a "p" suffix would help.

Thanks!

[cjmyers]

@jakebeal @bbartley I'm not sure this is a SynBioHub issue. The id's that are displayed are the ones in the SBOL that was uploaded. The user who created the SBOL could have used different ids, if they wanted to. If the ids are being autogenerated by pySBOL or if the confusion is in how you fetch things in pySBOL, then I think this may be a pySBOL issue.

You mentioned perhaps formatting of the data on SynBioHub could be better. Issues like that you could post, if you have suggestions that would help.

[rpgoldman]

@cjmyers Agreed: this is a matter of the "style sheet" to be used with SBOL. But it's nevertheless an issue with using SBOL and SBH.

I am not certain that one could solve this by formatting the data differently, because I am not sure that this distinction, between (proto)type and token is even something that can be captured by SBOL.

[cjmyers]

I'm not sure though what the ask is for SBH. SBH shows the ids/names that it was given. It seems that if we showed something different, it would be confusing to the user too.

[rpgoldman]

Sorry -- just saw your response. The ask is not for SBH per se -- the ask is for a "stylesheet" or something that says "typographically indicate the distinction between types and tokens," and "avoid using repeated names in SBOL models." For a specific example, I'd prefer to see

UWBF_OR_10_Network  :  UWBF_OR_10_Network_proto

instead of

UWBF_OR_10_Network  :  UWBF_OR_10_Network

I find the latter confusing.

I don't believe that SBOL offers a notion of prototype or class for this, so that one can have a particular network and a network template as we have here, does it? If it does, then my request is less pressing, because we can use the type system to make the distinction that I am asking for.

[jakebeal]

Two potential suggestions for how to proceed:

1. Have the libraries warn if an "instance" object (e.g., Component) is given the same name as its associated definition object (e.g., ComponentDefinition)
2. Also have SynBioHub indicate the type more visibly, so that in case one ignores the warnings, it's still easy to see which is the Component and which is the ComponentDefinition --- I constantly click on the wrong ones myself.

[cjmyers]

For suggestion 2, how might this be done. Below is an example where this is done. In this example, the names are different. Also, the instance is separated from the definition by a ":". I agree it is not always easy to see this. One option might be to have a proper table, but then I'm not sure what to do about the MapsTos. Any suggestions?

[jakebeal]

My problem with this is that my eye skips right past the labels in the headers, which aren't aligned with the material below in any case. Could you put the labels on the line instead?

e.g. Access: Public / Direction: none / Instance: gfp_fc / Definition: gfp

[rpgoldman]

One option might be to have a proper table, but then I'm not sure what to do about the MapsTos. Any suggestions?

What is the issue with the MapsTo? Is it just that they are optional? Or is it that they might require multiple lines in the table? Or something else?

[cjmyers]

@jakebeal Yes, we could put the labels in the line instead, but it will mean more lines will wrap.

@rpgoldman The issue with MapsTos is that it makes the line very long in some cases, like the one pictured, ex. (CDS2Component => CDS2Component_fc...).

[jakebeal]

I'm OK with lines wrapping when people use excessive names.

[rpgoldman]

@rpgoldman The issue with MapsTos is that it makes the line very long in some cases, like the one pictured, ex. (CDS2Component => CDS2Component_fc...).

Right, so I was thinking of doing the HTML equivalent of what one would do in Excel: make a column that has text-wrapping in it, so that each of the entries in MapsTo goes on its own line, but inside the same table row.

I am not an HTML expert, but I believe this could be achieved by having a MapsTo column in your table, and having the server emit <br/> tags between each of the MapsTo entries. In the case where there are a lot, this will put each on its own line, but inside the same table row -- you get a multi-line cell.

[cjmyers]

I think we can do a table, but I've found them a little trickier (see for example tables on Collection page). Is long wrapped lines with labels embedded or table to be preferred?

[rpgoldman]

If I was an HTML wizard, I would say "both", and have a magical way to use CSS to have the same HTML turn into either label-embedded form or table.

I suspect this is feasible by putting styles on the HTML you emit, putting the layout in the style sheet, and adding a button that will toggle between two different style sheets or somehow enabling and disabling different style sheets.

If this is of interest, I could ask some colleagues who are better at web layout than I am...

[cjmyers]

That is definitely beyond my expertise, so input would be useful. We can do Jake's approach simply enough, so we can start with that.

[danielfang97]

closing for now, as this seems to be related to the ontology issue

[rpgoldman]

@danielfang97 Maybe add a link to "the ontology issue"? I'm not sure what that refers to. Thanks

[danielfang97]

Hello, sorry, the issue is #340.

[cjmyers]

I think this a bit different than the ontology issue, reopening