Ontology should have non-specification glyphs and SVGs too

[jakebeal]

Right now, the ontology has links to only the PNGs for the specification glyphs (e.g., 'aptamer-specification.png').

The specification glyphs, however, are not generally the ones that we want to use directly in visualization; rather, we want to use 'aptamer.png' or, better yet, the rescalable 'aptamer.svg'.

We should add these to the ontology as well.

[goksel]

@jakebeal I still think we should not included all different versions of glyphs in the ontology. The ontology web service would be ideal to resolve images based on different requests. If you prefer to include this information in the ontology, could you please confirm how you would like to achieve this? I proposed a solution below. Currently, the README files are used to generate the ontology. The README files only include information about the specification PNG files but I can programmatically include other PNG files and the SVG files that should be used in designs.

Currently in the ontology:
defaultGlyph: aptamer-specification.png

Alternative solution: This would allow attaching other image formats (such as JPEG) or versions through multiple alternativeGlyph properties. A drawback would be not telling much about the actual images and their formats. I assume this is ok for now. We can further use image URIs and provide additional information, if we want to.
defaultGlyph: aptamer.svg
alternativeGlyph: aptamer.png
specificationGlyph: aptamer-specification.svg
alternativeSpecificationGlyph: aptamer-specification.png

[jakebeal]

I'd suggest a path that goes in between the two, in which we end up with two versions:

• defaultGlyph: aptamer.svg
• specificationGlyph: aptamer-specification.svg

The web service would then return the clean SVG by default, the specification SVG is requested, and optionally allow explicit specification of format.

[goksel]

@jakebeal I think this solution is ok. However, some glyphs do not have both SVGs. For example, assembly-scar does not include the non-specification glyph for the double strand version.
https://github.com/SynBioDex/SBOL-visual/tree/develop/Glyphs/assembly-scar

see stem-top:
https://github.com/SynBioDex/SBOL-visual/tree/master/Glyphs/cleavage-site

Moreover, PNG files are not provided for the non-specification glyphs, instead PDF files are provided. Although we will not use PNGs in the ontology, the web service would not be able to return PNG files for the new default glyphs anymore.
Some examples:
https://github.com/SynBioDex/SBOL-visual/tree/master/Glyphs/cds
https://github.com/SynBioDex/SBOL-visual/tree/master/Glyphs/chromosomal-locus

Any suggestion? Shall we leave this one for 2.4 milestone?

[jakebeal]

I don't actually see any missing SVGs.

• For assembly-scar, the actual glyph doesn't care about strand. The double-strand specification version is just there to illustrate that when you've got two strands, they still go between the bars, not aligned with them. The ontology should not reference assembly-scar-specification-doublestrand at all.
• Likewise, for cleavage-site and other stem-top glyphs, the ontology should not be referencing stem-top-specification. That is just there to illustrate the shared syntax of stem-top style glyphs.

Are there any others that you have concerns about?

As for the PDF vs. PNG - can you just run them through a converter? That's all I do (by hand) to produce the PNG or PDF in the first place. I only have the PNG because the Markdown renderer can't handle SVG, and the PDF is there primarily for historical reasons.

[goksel]

Let's move this to 2.4. It is not clear for me how to implement this. It would be great if we can come up with a generic rule for the conversion when creating the ontology.