This is a working document describing the rationale and protocol for a distributed sequence annotation system. See Changes for recent changes to the spec.
Extensions to the 1.0 specification introduced in version 1.5 are indicated in brown. These extensions should be backward compatible to clients and servers written for the 1.0 spec.
This section provides a high-level view of the system architecture.
The entry points describe the top level items on the reference sequence map. It is possible for each entry point to have substructure, basically a series of subsequences (components) and their start and end points. This structure is recursive. Each annotation is unambiguously located by providing its position as the start and stop positions relative to a "reference sequence." The reference sequence can be one of the entry points, or any of the subsequences within the entry point.
To give a concrete example, the C. elegans reference map consists of six chromosome-length entry points. Each chromosome is formed from several contigs called "superlinks", and each superlink contains one or more smaller contigs called "links". Links in turn are composed of one or more fully-sequenced clones. One could refer to an annotation by specifying its start or stop positions in clone, link, superlink, or chromosome coordinates. The distributed annotation system automatically converts any coordinate system into any other. Because coordinates within clones are more stable to revisions than coordinates within links or chromosomes, it is recommended that annotation coordinates be stored relative to the smallest sequencing unit.
The hierarchy is extensible. If the C. elegans gene predictions were stable, it would make sense to store certain annotations, such as the positions of exons, relative to the transcriptional unit.
The DAS consists of a reference sequence server, and one or more annotation servers.
Annotation servers are specialized for returning lists of annotations across a certain region of the genome. Each annotation is anchored to the genome map by way of a start and stop position relative to one of the reference subsequences. Annotations have an ID that is unique to the server and a structured description that describes its nature and attributes. Annotations may also be associated with Web URLs that provide additional human readable information about the annotation.
Annotations have types, methods and categories. The annotation type is selected from a list of types that have biological significance, and correspond roughly to EMBL/GenBank feature table tags. Examples of annotation types include "exon", "intron", "CDS" and "splice3." The annotation method is intended to describe how the annotated feature was discovered, and may include a reference to a software program. The annotation category is a broad functional category that can be used to filter, group and sort annotations. "Homology", "variation" and "transcribed" are all valid categories. The existence of these categories allows researchers to add new annotation types if the existing list is inadequate without entirely losing all semantic value. The Annotation Categories section contains a list of the annotation types in use in the C. elegans project.
It is intended that larger annotation servers provide pointers to human-readable data that describes its types, methods and categories in more detail. Another optional feature of annotation servers is the ability to provide hints to clients on how the annotations should be rendered visually. This is done by returning a XML "stylesheet".
The reference sequence server is an annotation server that provides the following additional services:
Although the servers are conceptually divided between reference servers and annotation servers, there is in fact no key difference between them. A single server can provide both reference sequence information and annotation information. The main functional difference is that the reference sequence server is required to serve the sequence map and the raw DNA, while annotation servers have no such requirement.
The DAS is Web-based. Clients query the reference and annotation servers by sending a formatted URL request to the server. This request must follow the conventions of the HTTP/1.0 protocol (see RFC2616. Servers process the request and return a response in the form of a formatted XML document (see W3C Extensible Markup Language).
All DAS requests take the form of a URL. Each URL has a site-specific prefix, followed by a standardized path and query string. The standardized path begins with the string /das. This is followed by URL components containing the data source name and a command. For example:
http://www.wormbase.org/db/das/elegans/features?segment=CHROMOSOME_I:1000,2000
^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^ ^^^^^^^ ^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
site-specific prefix das data command arguments
src
The data source component allows a single server to provide information on several genomes.
More information on the format of the request and the various available commands is given below.
The query string portion of the request (the "?" symbol rightward) can be POSTed to the URL following conventional HTTP standards. Since some queries can be quite large, this is the recommended way of argument passing.
Warning: The request may be replaced with a SOAP-style XML-encapsulated document in future versions of this specification.
Here is an example HTTP header: (provided by Web server)
HTTP/1.1 200 OK Date: Sun, 12 Mar 2000 16:13:51 GMT Server: Apache/1.3.6 (Unix) mod_perl/1.19 Last-Modified: Fri, 18 Feb 2000 20:57:52 GMT Connection: close Content-Type: text/plain X-DAS-Version: DAS/1.5 X-DAS-Status: 200 X-DAS-Capabilities: error-segment/1.0; unknown-segment/1.0; unknown-feature/1.0; ... data follows...
The defined status codes are listed in Table 1.
| 200 | OK, data follows |
|---|---|
| 400 | Bad command (command not recognized) |
| 401 | Bad data source (data source unknown) |
| 402 | Bad command arguments (arguments invalid) |
| 403 | Bad reference object (reference sequence unknown) |
| 404 | Bad stylesheet (requested stylesheet unknown) |
| 405 | Coordinate error (sequence coordinate is out of bounds/invalid) |
| 500 | Server error, not otherwise specified |
| 501 | Unimplemented feature |
The HTTP/1.0 protocol allows web clients to request byte-level compression of the response by sending the HTTP header Accept-Encoding header. Web servers that are capable of it can reply with a Content-transfer-encoding header and a compressed body. Implementors of DAS clients and servers may wish to implement this HTTP feature.
| New in version 1.5 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The X-Das-Capabilities header provides an extensible list of the
capabilities that the server provides. This can be used by those
writing experimental extensions to DAS to flag clients that those
extensions are available. Capabilities have the form
CapabilityName/Version and are separated by semicolon,
space, as in "capabilityA/1.0; capabilityB/1.4;
capabilityC/1.0". The following standard capabilities
are present in the DAS/1.5 protocol:
|
Reference sequence IDs indicate a segment of the genome. They can correspond to low-level primary sequences such as sequenced clones, or to higher-level assemblies such as contigs.
A reference ID can contain any set of printable characters (including the space character), but not the colon character (":"), which is reserved for separating reference IDs from sequence ranges (see below). The newline, tab and carriage return characters are also reserved for future use.
A data source that uses the colon character for its internal IDs must map this character to another one on the way out and on the way in. For example:
Client request server's internal id Response to client gi-123456 --> gi:123456 ---> gi-123456 gi-123456:1,1000 --> gi:123456 start=1 stop=1000 ---> gi-123456:1,1000
This section lists the queries recognized by reference and annotation servers. Each of these queries begins with some site-specific prefix, denoted here as PREFIX. The other meta-variable used in these examples is DSN, which is a symbolic data source. (As seen the the above example.) Data sources are standardized across DAS servers in such a way that a data source name has a one-to-one correspondence with a reference sequence.
Scope: Reference and annotation servers.
Command: dsn
Format:
PREFIX/das/dsn
Description: This query returns the list of data sources that are available from this server.
The response to the dsn command is the "DASDSN" XML-formatted document:
Format:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASDSN SYSTEM "http://www.biodas.org/dtd/dasdsn.dtd">
<DASDSN>
<DSN>
<SOURCE id="id1" version="version">source name 1</SOURCE>
<MAPMASTER>URL</MAPMASTER>
<DESCRIPTION>descriptive text 1</DESCRIPTION>
</DSN>
<DSN>
<SOURCE id="id2" version="version">source name 2</SOURCE>
<MAPMASTER>URL</MAPMASTER>
<DESCRIPTION href="url">descriptive text 2</DESCRIPTION>
</DSN>
...
</DASDSN>
Scope: Reference servers.
Command: entry_points
Format:
PREFIX/das/DSN/entry_points
Description: This query returns the list of sequence entry points available and their sizes in base pairs.
Arguments:
The response to the entry_points command is the "DASEP" XML-formatted document:
Format:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASEP SYSTEM "http://www.biodas.org/dtd/dasep.dtd">
<DASEP>
<ENTRY_POINTS href="url" version="X.XX">
<SEGMENT id="id1" start="start1" stop="stop1" type="type" orientation="+">descriptive text</SEGMENT>
<SEGMENT id="id2" start="start2" stop="stop2" type="type" orientation="+">descriptive text</SEGMENT>
<SEGMENT id="id3" start="start3" stop="stop3" type="type" orientation="+">descriptive text</SEGMENT>
...
</ENTRY_POINTS>
</DASEP>
The href (required) attribute echoes the URL query that was used to fetch the current document.
If the optional subparts attribute is present and has the value "yes", it indicates that the segment has subparts.
If the optional type attribute is present, it can be used to describe the type of the segment (for future compatibility with Sequence Ontology-based feature typing).
For compatibility with older versions of the specification, the <SEGMENT> tag can use a size attribute rather than start and stop, and can omit the orientation attribute:
<SEGMENT id="id" size="123456">
In this case, the start is implied to be "1" and the stop is implied to be the same
as the length.
Scope: Reference servers.
Command: dna
Format:
PREFIX/das/DSN/dna?segment=RANGE[;segment=RANGE...]
Description: This query returns the DNA corresponding to the indicated segment.
Arguments:
Here is an example of a valid request that uses the segment argument to fetch three non-overlapping segments:
http://www.wormbase.org/db/das/elegans/dna?
segment=CHROMOSOME_I:1,1000;segment=CHROMOSOME_II:5000,5200;segment=ZK154
The response to dna is the "DASDNA" XML-formatted document.
Format:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASDNA SYSTEM "http://www.biodas.org/dtd/dasdna.dtd">
<DASDNA>
<SEQUENCE id="id" start="start" stop="stop" version="X.XX">
<DNA length="NNNN">
atttcttggcgtaaataagagtctcaatgagactctcagaagaaaattgataaatattat
taatgatataataataatcttgttgatccgttctatctccagacgattttcctagtctcc
agtcgattttgcgctgaaaatgggatatttaatggaattgtttttgtttttattaataaa
taggaataaatttacgaaaatcacaaaattttcaataaaaaacaccaaaaaaaagagaaa
aaatgagaaaaatcgacgaaaatcggtataaaatcaaataaaaatagaaggaaaatattc
agctcgtaaacccacacgtgcggcacggtttcgtgggcggggcgtctctgccgggaaaat
tttgcgtttaaaaactcacatataggcatccaatggattttcggattttaaaaattaata
taaaatcagggaaatttttttaaattttttcacatcgatattcggtatcaggggcaaaat
tagagtcagaaacatatatttccccacaaactctactccccctttaaacaaagcaaagag
cgatactcattgcctgtagcctctatattatgccttatgggaatgcatttgattgtttcc
gcatattgtttacaaccatttatacaacatgtgacgtagacgcactgggcggttgtaaaa
cctgacagaaagaattggtcccgtcatctactttctgattttttggaaaatatgtacaat
gtcgtccagtattctattccttctcggcgatttggccaagttattcaaacacgtataaat
aaaaatcaataaagctaggaaaatattttcagccatcacaaagtttcgtcagccttgtta
tgtcaaccactttttatacaaattatataaccagaaatactattaaataagtatttgtat
gaaacaatgaacactattataacattttcagaaaatgtagtatttaagcgaaggtagtgc
acatcaaggccgtcaaacggaaaaatttttgcaagaatca
</DNA>
</SEQUENCE>
</DASDNA>
| New in Version 1.5: this is a generalization of the DNA request to allow fetching of non-DNA sequences |
|---|
Retrieve the Sequence Associated with a SubsequenceScope: Reference servers. Command: sequence Format: PREFIX/das/DSN/sequence?segment=RANGE[;segment=RANGE...] Description: This query returns the sequence (nucleotide or protein) corresponding to the indicated segment. Arguments:
Here is an example of a valid request that uses the segment argument to fetch three independent segments. The last segment is a subsequence:
http://www.wormbase.org/db/das/elegans/sequence?
segment=BUM;segment=HUM_HGA;segment=CE_HOC2:1,200
The Sequence ResponseThe response to dna is the "DASSEQUENCE" XML-formatted document. Format:
|
Scope: Annotation and reference servers.
Command: types
Format:
PREFIX/das/DSN/types [?segment=RANGE]
[;segment=RANGE]
[;type=TYPE]
[;type=TYPE]
Description: This query returns the annotation available for a segment of sequence.
Arguments:
For compatibility with versions 0.997 and earlier of this protocol, servers are allowed to treat the type ID as a regular expression, but this feature is deprecated and should not be used.
If one or more segment arguments are provided, the list of types returned is restricted to the indicated segments. If no segment argument is provided, then all feature types known to the source are returned.
The document returned from the types request is an XML-formatted "DASTYPES" documents. This is a shortened form of the full features format (see below) and is used to summarize the type and number of each annotation. Annotation types can be grouped into segments, or be totaled across the entire database.
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASTYPES SYSTEM "http://www.biodas.org/dtd/dastypes.dtd">
<DASTYPES>
<GFF version="1.0" href="url">
<SEGMENT id="id" start="start" stop="stop" type="type" version="X.XX" label="label">
<TYPE id="id1" method="method" category="category">Type Count 1</TYPE>
<TYPE id="id2" method="method" category="category">Type Count 2</TYPE>
...
</SEGMENT>
</GFF>
</DASTYPES>
Scope: Reference and annotation servers.
Command: features
Format:
PREFIX/das/DSN/features?segment=REF:start,stop[;segment=REF:start,stop...]
[;type=TYPE]
[;type=TYPE]
[;category=CATEGORY]
[;category=CATEGORY]
[;categorize=yes|no]
[;feature_id=ID]
[;group_id=ID]
Description: This query returns the annotations across one or more segments of sequence.
Arguments:
For compatibility with versions 0.997 and earlier of this protocol, servers are allowed to treat the type ID as a regular expression, but this feature is deprecated and should not be relied on.
For compatibility with versions 0.997 and earlier of this protocol, servers are allowed to treat the type ID as a regular expression, but this feature is deprecated and should not be relied on.
Annotation servers are only required to return annotations which are completely contained within the indicated segment. Servers may also return annotations which overlap the segment, but are not completely contained within them. Annotations must be returned using the coordinate system in which they were requested. For example, if a contig ID was used to specify the segment, then the annotation endpoints must use contig coordinates.
If multiple segment arguments are provided and they happen to overlap, then the annotation server may return the same annotation multiple times, possibly using different coordinate systems. It is the responsibility of the client to merge annotations based on the assembly.
The document returned from the features request is an XML-formatted "DASGFF" document.
Format:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASGFF SYSTEM "http://www.biodas.org/dtd/dasgff.dtd">
<DASGFF>
<GFF version="1.0" href="url">
<SEGMENT id="id" start="start" stop="stop" type="type" version="X.XX" label="label">
<FEATURE id="id" label="label">
<TYPE id="id" category="category" reference="yes|no">type label</TYPE>
<METHOD id="id"> method label </METHOD>
<START> start </START>
<END> end </END>
<SCORE> [X.XX|-] </SCORE>
<ORIENTATION> [0|-|+] </ORIENTATION>
<PHASE> [0|1|2|-]</PHASE>
<NOTE> note text </NOTE>
<LINK href="url"> link text </LINK>
<TARGET id="id" start="x" stop="y">target name</TARGET>
<GROUP id="id" label="label" type="type">
<NOTE> note text </NOTE>
<LINK href="url"> link text </LINK>
<TARGET id="id" start="x" stop="y">target name</TARGET>
</GROUP>
</FEATURE>
...
</SEGMENT>
</GFF>
</DASGFF>
The reference server's annotations can consist of additional overlapping landmarks (parents, children, and neighbors), which should be marked "yes" in the third attribute reference (optional, defaults to "no") to indicate that the feature is a structural landmark within the map (this feature can be annotated). The tag contents (optional) is a human readable label for display purposes.
If a reference annotation has either or both of the optional attributes, subparts="yes" and superparts="yes", then in addition to being useable as a reference sequence, the feature contains subparts and/or superparts that themselves can act as reference features. This can be used to reconstruct reference server's assembly. See also Fetching Assembly Information.
The group id attribute (required) provides an identifier that should be used by the client to group features together visually. Unlike other IDs in this protocol, the group ID cannot be used as a database handle to retrieve further information about the group. Such information can, however, be provided within <GROUP> section, which may contain up to three optional tags.
The label attribute (optional) provides a human-readable string that can be used in graphical representations to label the glyph.
The type attribute (optional) provides a type ID for the group as a whole, for example "transcript". This ID can be used as a key into the stylesheet to select the glyph and graphical characteristics for the group as a whole.
| New in version 1.5: Exception Handling for Invalid Segments |
|---|
|
The request for a named segment may fail because: (1) the
reference sequence is not known to the server or (2) the
requested region is outside the bounds of the segment. In both
cases, an exception is indicated.
In the case of a reference server, which is expected to be authoritative for the map, the <GFF> section will flag the problem by issuing an <ERRORSEGMENT> tag instead of the usual <SEGMENT> tag. This tag has the following format:
<ERRORSEGMENT id="id" start="start" stop="stop"> The id attribute (required) corresponds to the ID of the requested segment, and start and stop (optional) correspond to the requested bounds of the segment if this was specified in the request. Unlike a reference server, an annotation server is not required to know the identities of all the segments. Therefore when presented with a segment ID that it doesn't recognize, it can't know whether this is a true client error or merely an unannotated segment. In this case, an annotation server will issue an <UNKNOWNSEGMENT> tag. This tag has the same syntax as <ERRORSEGMENT> but doesn't necessarily imply an error. If an annotation server detects a request for a region outside the bounds of a segment that it has annotated, it will issue an <ERRORSEGMENT> exception. In the case of a request for multiple segments, the server will return a mixture of <SEGMENT> sections for valid segments, and <ERRORSEGMENT> or <UNKNOWNSEGMENT> sections for invalid ones. |
Scope: Annotation servers.
Command: link
Format:
PREFIX/das/DSN/link?field=TAG;id=ID
Description: This query can be issued in order to retrieve further human-readable information about an annotation. It is best to pass this URL directly to a browser, as the type of the returned data is not specified (it will typically be an HTML file, but any MIME format is allowed).
Arguments:
Response: A web page.
Scope: Annotation servers.
Command: stylesheet
Format:
PREFIX/das/DSN/stylesheet
Description: This query can be issued to an annotation server in order to retrieve the server's recommendations on formatting annotations retrieved from it. These recommendations are not normative. A viewer is free to use any display format it chooses.
Arguments: None.
This document is intended to provide hints to the annotation display client. It maps feature categories and individual types to a series of glyphs known to the display client.
Format:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE DASSTYLE SYSTEM "http://www.biodas.org/dtd/dasstyle.dtd">
<DASSTYLE>
<STYLESHEET version="X.XX">
<CATEGORY id="default">
<TYPE id="default">
<GLYPH zoom="high">
<ID>
<ATTR>value</ATTR>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
<GLYPH zoom="medium">
<ID>
<ATTR>value</ATTR>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
<GLYPH zoom="low">
<ID>
<ATTR>value</ATTR>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
</TYPE>
</CATEGORY>
<CATEGORY id="group">
<TYPE id="group_id1">
<GLYPH zoom="high">
<ID>
<ATTR>value</ATTR>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
...
</CATEGORY>
<CATEGORY id="category1">
<TYPE id="default">
<GLYPH>
<ID>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
</TYPE>
<TYPE id="type1">
<GLYPH>
<ID>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
</TYPE>
<TYPE id="type2">
<GLYPH>
<ID>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
</TYPE>
...
</CATEGORY>
<CATEGORY id="category2">
<TYPE id="default">
<GLYPH>
<ID>
<ATTR>value</ATTR>
...
</ID>
</GLYPH>
</TYPE>
...
</CATEGORY>
...
</STYLESHEET>
</DASSTYLE>
Here is a short stylesheet example:
...
<CATEGORY id="Similarity">
<TYPE id="default">
<GLYPH>
<LINE>
<FGCOLOR>gray</FGCOLOR>
</LINE>
</GLYPH>
</TYPE>
<TYPE id="NN">
<GLYPH >
<BOX>
<HEIGHT>4</HEIGHT>
<FGCOLOR>black</FGCOLOR>
<BGCOLOR>red</BGCOLOR>
</BOX>
</GLYPH>
</TYPE>
<TYPE id="NP">
<GLYPH>
<TOOMANY>
<HEIGHT>4</HEIGHT>
<FGCOLOR>black</FGCOLOR>
<BGCOLOR>blue</BGCOLOR>
</TOOMANY>
</GLYPH>
</TYPE>
<TYPE id="PN">
<GLYPH>
<BOX>
<HEIGHT>3</HEIGHT>
<FGCOLOR>blue</FGCOLOR>
<BGCOLOR>green</BGCOLOR>
</BOX>
</GLYPH>
</TYPE>
<TYPE id="PP">
<GLYPH>
<SPAN>
<HEIGHT>4</HEIGHT>
<FGCOLOR>gray</FGCOLOR>
</SPAN>
</GLYPH>
</TYPE>
</CATEGORY>
...
Groups can also have stylesheet entries. If present, they are located in the category named "group". Typically a group will be associated with the "line" glyph, which as described below, draws connections between the members of a group.
A sample stylesheet used for the WormBase DAS server can be found at http://www.biodas.org/documents/sample_stylesheet.xml.
Glyphs and their attributes are typically applied to individual features. However, they can be applied to entire groups as well (via the <GROUP> type attribute). In this case, the glyph will apply to the connecting regions between the components of the group.
For example, to indicate that the exons in a "transcript" group should be drawn with a yellow box, that the utrs should be drawn with a blue box, and that the connections between exons should be drawn with a hat-shaped line:
<CATEGORY id="Transcription">
<TYPE id="exon">
<GLYPH>
<BOX>
<BGCOLOR>yellow</BGCOLOR>
</BOX>
</GLYPH>
</TYPE>
<TYPE id="utr">
<GLYPH>
<BOX>
<BGCOLOR>blue</BGCOLOR>
</BOX>
</GLYPH>
</TYPE>
</CATEGORY>
<CATEGORY id="group">
<TYPE id="transcript">
<GLYPH>
<LINE>
<FGCOLOR>black</FGCOLOR>
<LINE_STYLE>hat</LINE_STYLE>
</LINE>
</GLYPH>
</TYPE>
...
Reference servers, but not annotation servers, must represent and serve genome assemblies.
The components of an assembly are treated as a set of features with a type category attribute of "component" and a reference attribute of "yes". Intermediate components of the assembly will also have a subparts attribute of "yes". Components that are the parents of the reference sequence in the assembly have a category attribute of "supercomponent."
For those components that have subparts, the start and end of the feature give the feature's position in the requested segment's coordinate system, and the id, start and end of the <TARGET> element gives the feature's position in its native coordinates.
For example:
1 200 400 1000
+--------+-----------+-------------------+ chr22
1 200 220 1 20 620
+--------+---- A --+-------------------+ B
1 80 280 400
------+-----------+-------- C
=================== C.1
============= C.2
A request for this assembly will look like the following:
http://www.wormbase.org/db/das/elegans/features?segment=chr22:1,1000;category=component
The reference server will return the following (abbreviated) document:
<SEGMENT id="chr22" start="1" stop="1000">
<FEATURE id="chr22">
<START>1</START>
<STOP>1000</STOP>
<TYPE id="Contig" category="component" reference="yes" superparts="no" subparts="yes">chr 22</TYPE>
<TARGET id="chr22" start="1" stop="1000">chr22</TARGET>
...
</FEATURE>
<FEATURE id="Contig:A">
<START>1</START>
<STOP>200</STOP>
<TYPE id="Contig" category="component" reference="yes" superparts="yes" subparts="no">a contig</TYPE>
<TARGET id="A" start="1" stop="200">Contig A</TARGET>
...
</FEATURE>
<FEATURE id="Contig:B">
<START>400</START>
<STOP>1000</STOP>
<TYPE id="Contig" category="component" reference="yes" superparts="yes" subparts="no">a contig</TYPE>
<TARGET id="B" start="20" stop="620">Contig B</TARGET>
...
</FEATURE>
<FEATURE id="Contig:C">
<START>200</START>
<STOP>400</STOP>
<TYPE id="Contig" category="component" reference="yes" superparts="yes" subparts="yes">a contig</TYPE>
<TARGET id="C" start="80" stop="280">Contig C</TARGET> ...
</FEATURE>
</SEGMENT>
Notice that contig C is marked as having subparts. This is an indication to the client that it should emit a features request that includes segment C:80,280 in order to discover its components (C.1 and C.2).
Notice also that chr22 appears as a component of itself with the attribute superparts="no" and subparts="yes". This is a side effect of providing information about the component parent.
It is also desirable for a client to fetch the parent of a segment, so as to accomodate the situation in which the user enters the browser at a contig or sequenced clone, and wants to "zoom out."
This situation is complicated by rough draft issues, in which a single rough draft sequence segment may have multiple parents, and some sections of the segment may not belong in the assembly at all. For example:
A B C D
contig21-----------> <-----------contig100
| | / /
| | / /
Acc A ---------------------
a b c d
Here, the segment "Acc A" contains two fragments, one of which is
located on contig21 and the other on contig100.
To retrieve this information, the client requests the category supercomponent. For segments that are in the middle of the assembly, one or more assembly parents will be returned in addition to subcomponents. The parent <START>, <STOP> and <ORIENTATION> tags are presented in the coordinate system of the requested segment, as always. The start and stop attributes of the <TARGET> tag, denote the corresponding segment in the coordinate system of the parent. As always, start is less than stop, for both the feature and the target.
<SEGMENT id="Acc A" start="1" stop="1000">
<FEATURE id="contig21_goldenpath_map">
<START>a</START>
<STOP>b</STOP>
<ORIENTATION>+</ORIENTATION>
<TYPE id="Contig" category="supercomponent" reference="yes" superparts="yes" subparts="yes">a contig</TYPE>
<TARGET id="contig21" start="A" stop="B"></TARGET>
</FEATURE>
<FEATURE id="contig100_goldenpath_map">
<START>c</START>
<STOP>d</STOP>
<ORIENTATION>-</ORIENTATION>
<TYPE id="Contig" category="supercomponent" reference="yes" superparts="yes" subparts="yes">a contig</TYPE>
<TARGET id="contig100" start="D" stop="C"></TARGET>
</FEATURE>
</SEGMENT>
To continue following the parents upward in the assembly, the client will issue further features requests for the target IDs, in this case "contig21" and "contig100". In the general case, following parents will project the requested segment onto a discontinuous set of regions, potentially on different chromosomes. The client may wish to alert the user and refuse to proceed further when it encounters a segment with multiple parents.
This is a list of generic feature categories and specific feature types within them. This list was derived from the features currently exported by ACeDB/GFF and is not comprehensive. Suggestions for modifications, additions and deletions are welcomed.
This category indicates that the feature is a child component of the reference sequence in the current assembly. When combined with the reference="yes" attribute, this indicates that the feature can be used as a reference point to retrieve subfeatures contained within it (including subcomponents).
This category indicates that the feature is the parent of the reference sequence in the current assembly. When combined with the reference="yes" attribute, this indicates that the feature can be used as a reference point to retrieve features that completely contain the selected range of the reference sequence.
The translation category is used for features that relate to regions of the sequence that are translated into proteins. Features that relate to transcription are separate (see below).
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the transcription feature.
The transcription category is used for features that relate to regions of the sequence that are transcribed into RNA.
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the transcription feature.
The variation category is used for features that relate to regions of the sequence that are polymorphic.
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the variation.
The structural category is used for features that relate to mapping, sequencing and assembly, as well as for various landmarks that carry no intrinsic biological information.
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the structural feature.
The similarity category is used for areas that are similar to other sequences. Similarity features should have a <METHOD> tag that indicates the algorithm used for the sequence comparison, and a <TARGET> tag that indicates the target of the match.
Features:
The repeat category is used for areas that contain repetitive DNA. This category is used both for low-complexity regions, such as microsatellites, and for more biologically interesting features, such as transposon insertion sites.
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the repetitive element.
The experimental category is a catchall used to flag areas where there is interesting experimental data of one sort or another. It is intended for use with high-throughput functional genomics work, such as knockouts or insertional mutagenesis screens.
Features:
It is recommended, but not required, that the <FEATURE> section contain <LINK> and/or <NOTE> tags that provide further information on the nature of the experimental data.
This section describes a set of generic "glyphs" that can be used by sequence display programs to display the position of features on a sequence map. The annotation server may use these glyphs to send display suggestions to the viewer via the stylesheet document.
The current set of glyph ID values are:
Each glyph has a set of attributes associated with it. Attribute values come in the following flavors:
Some attributes are shared by all glyphs. Others are glyph-specific. The following attributes are shared in common:
Attributes:
Attributes:
Attributes:
Attributes:
(no glyph-specific attributes)
Attributes:
(no glyph-specific attributes)
Attributes:
(no glyph-specific attributes)
A feature that is invisible, intended to support semantic zooming schemes in which a feature is hidden at particular zooms.
Attributes: none.
Attributes:
Attributes:
(no glyph-specific attributes)
Attributes:
Two inward-pointing arrows connected by a line of a different color. Used for showing primer pairs and a PCR product. The length of the arrows is meaningless.
There are no glyph-specific attributes, but in this context the foreground color is the color of the arrows, and the background color is the color of the line that connects them.
Attributes:
Attributes:
The distributed annotation system must have a mechanism for detecting and resolving version skew across reference and annotation servers. Although one such mechanism is currently incorporated into the ACeDB-based prototype, it is largely untested and hence not yet a part of the DAS standard.
This section was added at version 0.99.