Viewing the images of Glycan Structures are a critical aspect of Glycan research. In general, images are the simplest method used to describe and convey the structure. The most common formats used are CFG, IUPAC, or Oxford.

As the Glycan repository for nearly any glycan structure, it is important for the system to be able to handle displaying of glycan structures quickly and in a variety of formats. How the repository manages images will be described in detail in this document.


For all new registrations, the base sequence format stored is WURCS. As of this writing, the WURCS image generation method is still under construction so the glycoCT-based image generation in GlycanBuilder will be used primarily. The registration process already generates KCF, glycoCT, Linearcode, and the base format WURCS, so this should not be a problem. It should be noted that the framework should be flexible enough to replace the image generation method. Thus how the image is generated should also be a property of the image RDF.

Base Case

The base case is where the repository is completely blank. In this case there is no structure nor image information. So the entire process should start by the registration of a new structure.


Before registration, the generation of the image is required before submitting the structure. This is a critical aspect of the registration process, as it confirms the structure to be registered. This is currently created by hex-encoding the image and then displayed on the browser.

The hex-encoding of the image is generated by the GlycanBuilder Library. After confirmation, the user can submit the structure, which will then be given an accession number.

Once registered, the GlycanBuilder library is used to generate an image file in png and svg formats. All of the glycoinformatic formats possible should be created, using CFG, IUPAC, Oxford, or any combination.

The newly registered structure will also store the related data for the image in RDF.

The glycoRDF, FOAF, schema and DC owl will be used.

glycoRDF details can be found here.

RDF for image data is covered in detail here.

However there is also image data that is recognized by search engines in the ontology.

The ImageRdf class is used to extract the information required for these ontologies.

Here is an example of a structure ID G00054MO being registered. Note the dc:creator and URI used specifies the program used to generate the image.


PREFIX glycan: <>
<> a glycan:saccharide ;
  glycan:has_image <> .

PREFIX glycan: <>
<> a glycan:image ;
 glycan:has_symbol_format	glycan:symbol_format_cfg ;


PREFIX dc: <>
PREFIX glycan: <>

<> a glycan:image ;
dc:title "GlyTouCan registered structure ID: G00054MO" ;
dc:creator "GlycanBuilder v1.0" ;
dc:date "1996" ;
dc:description "GlyTouCan registered structure ID: G00054MO." ;
dc:format	"image/png"^^xsd:string ;


PREFIX foaf: <>
PREFIX glycan: <>
<> a glycan:saccharide ;
foaf:thumbnail "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAALoAAABSCAIAAABse1lJAAACX0lEQVR42u3boW7CUBSA4ZtJgiBZsiAQCAQSgUAieIhJRAWiEoEhQZCAQCAQ8AgkCCQCh1mCQCCQPAIC0WSI7WQ1JNtYYVvPKfn/9AGay8ftvdzi3ogi5xgCggvBheBCcCG4EFwYAoILwYXgQnAhuBBcGAKCC8GF4EJwIbgQXBgCggvBheBCcCG4EFwYAoILwYXgQnBJfKfTiXuLlYv7i1QGZbVaFQqF3W5n0MpmsymVSlpi/pvL6+8up2Ll0T16zsvlctbEiJJisTgYDO51dkkYl9DKxE1e3EvP9ayJWSwWwuWOH0ZJ4nJuJbysiWm1Wp1O5z6Xusni8tmKQTH1er3f78NFmct3VqyJ8TxvPB7DRZPLZSumxMjU4vs+XNS4RLFiR4wsdcvlMlx0uES3YkTM8XhMp9NBEMAlbi7XWjEiplqtzudzuMTK5TYrFsQMh0PZH8Hlay7/1IN7aLv2DVbC69k9O71SqRSHALHOLrPZ7Mk9Td30BisyJ2WzWZmftL7ilUpluVzCJda1y21i1K1I3W630WjAJe6d0bViLFiRZNmUz+fhovC7S3QxRqyEZTKZ/X4PF4VfdaOIMWVFqtVqcttw0TkzuizGmhWp2WyqnDXC5QcxBq1Ivu+rvMkAl0tibFp5+3iTYTQawUX5bbpzMWatBEEgO6P1eg0X/Xd1QzFt17ZpRZLHkNa5NP8E+FqM7FRtWjkcDuJ4u93eG5dEJ58K9wYXggvBheBCcCG4EMGF4EJwIbgQXAguRHAhuBBcCC4EF4ILEVwILgQXggvBheBCBBeCC8GF4ELJ7h28Fpg2gJRZSwAAAABJRU5ErkJggg==" .

<div vocab="" typeof="ImageObject">
  <h2 property="name">Beach in Mexico</h2>
  <span rel="contentURL"><img src="mexico-beach.jpg" /></span>

  By <span property="author">Jane Doe</span>
  Photographed in
    <span property="contentLocation">Puerto Vallarta, Mexico</span>
  Date uploaded:
    <span property="publishDate" content="2008-01-25">Jan 25, 2008</span>

  <span property="description">I took this picture while on vacation last year.</span>

Batch Processes

In the case of volume registrations, a batch upload process should also be considered. This process will reuse the registration procedure to generate the image RDF for a large volume of structures.

Batch process class name:


Web Service

The image binary web service will be altered so that when a specific image of an ID is requested, the RDF is checked for the binary and that data will be retrieved. The web service will handle the parameters to find the specific format requested.

If it is not found, then a not found image will be displayed.


Once the above image data is stored, it is possible to retrieve the image using sparql.

The current image web service allows for the following to display a binary image:

This is implemented in the following class:, String, String, String)

It currently retrieves the glycoct and executes the GlycanBuilder generation process to create them.

Instead the hex-encoded data can be retrieved directly using sparql. This can then be converted into a binary image and displayed.

PREFIX foaf: <>
PREFIX dc: <>
PREFIX glycan: <>
SELECT ?data
  ?glycan glycan:has_primary_key "G00054MO" .
  ?glycan glycan:has_image ?glycanImage .
  ?glycanImage foaf:thumbnail ?data .
  ?glycanImage glycan:has_symbol_format	glycan:symbol_format_cfg ;
  ?glycanImage dc:format "image/png"^^xsd:string ;


By storing the hex-encoded data directly into the RDF, the image-generation dependency and point of failure is removed. It is also possible to alter the registration process to completely regenerate all images using a different generation program.

Once the wurcs image generation program is ready, it can be quickly integrated into this system to have a robust method of displaying structure images.