Exchange format for LSDBs

Tomasz, thanks for the useful link!

Juha - on a general, perhaps intuitive note, data elements of a simple type which have a one-to-one relationship with the parent element usually work fine as attributes. For instance, it would be fairly conventional to do something like this:

<variant id="foobar" datecreated="2009-11-01" datelastmodified="2009-12-01">
[more complex stuff]
</variant>

But regarding that specific element, 'name' which one would normally assume is merely a simple string or label - in fact this is a much more complex structure which isn't a name anymore. Which brings me to another point: the HGVS string/name is a hugely semantically-overloaded construct. I can truly understand how having the label is useful when working with an LSDB, don't get me wrong. However, if that's all you provide in the XML then that places a burden on the data consumer, namely to extract the information embedded in the name according to various idiosyncrasies of naming schemes etc.

Therefore, I suggest that the coordinates and type (genomic, cDNA) information be presented separately in the XML separately in a structured way, along with the HGVS name which can then be treated (by the client) as an opaque label for the variant.

>Implementation specific things like global ids should go into attributes, if those are needed. (?)
><variant id="lsid://findis.org/variant/00001" />

I think we should not sidestep the issue of IDs as something that will be 'dealt with' in some implementation or the other. Why not put it in the spec that the globally-unique identifier held in this attribute should ideally be a http-resolvable URI? For instances, LRG's which have a permant ID should (at some point I hope) have a stable URI which can be followed by clients to look up to find 'useful information' (as in Linked Data):

<variant uri="http://findis.org/variant/00001">
<ref_seq uri="http://[future base URL for LRGes/LRG000001" />
[more stuff]
</variant>
If a URI for some reason is not feasible for a given identifier, then alternatively (or additionally) provide a fully-fledged db-crossref construct containing accession AND database/namespace to go with it, something like this:

<ref_seq>
<db_xref accession="LRG000001" databaseName="LRG" />
</ref_seq>

This is pretty traditional - see e.g. DatabaseReference and Database in the Fuge model and a similar construct in PaGE.

My point here is that if I (speaking as a potential consumer/aggregator of this variant information) am given some opaque identifier without a context, I have no idea what to do with it Variant ID "00000012"? reference sequence LRG000003?

To counter this, I suggest explicitly stating in the spec that the variant should have (ideally) a URI (and emphasize the Linked Data connection) or, failing that, a full db_xref.

Hi guys,

To trow my 2 cents in, I found Tomasz' link really useful, and propose the following adaptations / agree with the following suggestions:

- "naming_scheme" would be standardized enough in my opinion, to be an attribute of "name".

- I like the suggestion to add "uri" or "id" attributes to the "variant" element, carrying a resolvable URI.

- I believe dates / times should not be an attribute. You could simply define the structure as "YYYY-MM-DD" but a true timestamp should carry time zone information as well, making them in my opinion too extensive to be a simple attribute.

- If the "ref_seq" points to an URI, I'd prefer the format name as an added attribute; like the "database_name" that comes with an accession number, as suggested by Mummi.

Following up on the coordinates thing - We're talking about passing around what are essentially features on some reference sequence or the other, right? Has it been investigated whether existing XML sequence feature formats and exchange protocols can be reused & extended for this purpose?

I don't mean to be a party-pooper here, but oftentimes it seems like we're getting awefully close to inventing yet another feature format....

Interesting. Have you tried asking in the LRG group?http://www.gen2phen.org/groups/locus-reference-genomics-lrg

Raymond - I have to disagree with you there: VCF is not a naming scheme, it´s format for representing variant sites in the genome sequence in a structured (and rather GFF-like) way. The HGVS scheme is a system for creating handy string labels for variants, albeit labels which are semantically-overloaded (see above: http://www.gen2phen.org/post/exchange-format-lsdbs#comment-165). So, another apples vs [some other fruit] comparison, I feel!

Juha, I can't seem to be able to find such an example. ALT in the example on the link Raymond provided contains "alternate non-reference alleles" - but that means something like "A" or "G,T", or ".". To understand the whole mutation, you'll need at least three other fields - chromosome (CHROM), position (POS), and (I believe) the reference nucleotide (REF). The strength of the HGVS nomenclature is in providing all this information in one field - although re-interpreting that information from that one field is harder to code.

Ivo / Juha - the 'strength' of the HGVS nomenclature obviously lies in its ease-of-reading by a human. But what we are concerned with here is data exchange between computers and machine-readability of this information. That is why the 'editing instructions' as Juha calls it also need to be present in structured form. So, to me it isn't a question of 'should we' build this into the variant exchange model but rather 'how' .

Ivo - I would provide both. Recipient data consumers which prefer the HGVS 'smart' name and are aware of the semantics can use that, others (myself included) would treat the HGVS name as merely a label and use the structured version of the same information.

BTW You'll find that other systems generally store this information in a structured way (BioSQL, Bio::DB::GFF and Bio::DB::SeqFeature::Store in BioPerl, Chado in the GMOD collection etc.), not the least because a major requirement in this domain is to query a genome-wide database for certain kinds of features in a specific genomic interval. Which clearly is not a requirement for LOVD, as you only store the HGVS name.

My guess is that VCF can't handle big deletions, insertions, duplications or rearrangements, inversions are probably interpreted as deletions/insertions, and whole-exon deletions or duplications (even if relatively small) with unknown breakpoints in the flanking introns probably can't be stored. The other systems Mummi mentioned, I have never looked in to. Maybe these don't have those problems.

About the Mutalyzer API: LOVD currently uses a very basic interface to communicate to Mutalyzer. There are already plans to update it and improve it, but I really have no clue what the timeline would be.