I can see both arguments, for the existing standard single letters, and for long names.

Over all I am weakly on the side of using names.  We can say at the start of the enum that this consciously supports
the same information as CIGAR as used in BAM, CRAM etc., and put the CIGAR symbols in comments, e.g. // I in CIGAR

But I don't believe it is the case that people who know CIGAR will know the names - they never look at them.
Also I think that Cassie's comment that there will be rapid adoption of the GA4GH interface and that CIGAR
will dissappear rapidly needs a reality check - apart from the established infrastructure around BAM and all
the mapping software, CIGAR is also used in the genome browsers, model organism databases  and many 
other places.  People in this group may be the brave new world, but we have to bring the old world with us
and it will take a long time.

On the other hand, I agree that once we are not looking at the storage but rather the logical form, meaningful
names are good as long as they are reasonably concise.  I would prefer "pad" to "padding", "soft_clip" to "soft_clipping",
"hard_clip" to "hard_clipping" and probably "skip" to "skipped_region".  These are more in line with "match",
"insertion" etc.

I am sympathetic with the desire to collapse M, = and X: I always found that a bit annoying.  But again for reasons of
logical continuity I advise to retain them for the time being.  We could agree which one we want in the long run and
deprecate the others, with a comment that they are present to support complete interconversion with the BAM model,
but we advise to use an alternative.  I guess we would prefer M, and deprecate = and X.  In that case I would be
tempted to call M "match" not "alignment_match", emphasizing its primary status.  If you succeed in eliminating = and
X it will look a bit odd to call M "alignment_match".

Richard

On 29 Apr 2014, at 20:07, cassiedoll <notifications@github.com> wrote:

> In src/main/resources/avro/ga4gh.avdl:
> 
> > @@ -63,6 +68,27 @@ record GAReadSet {
> >    union { null, array<GAReferenceSequence> } referenceSequences = null;
> >  }
> >  
> > +enum GACigarOperation {
> > +    M, I, D, S, H, N, P, V, X // V represent the sequence match operation (=) in SAM
> Hmm. I disagree here. A user who knows SAM most likely translates the letter M to something in their head. It would be great to get that auto-translation into the spec itself to increase ease of use. Over time, the percentage of users that are familiar with SAM should radically decrease. (At least that should be the hope/goal! :)
> 
> I personally have no idea what any of the letters mean and have to look them up in the SAM spec every time.
> 
> I'm ok with putting the unification into another pull request (I agree with Frank's sentiment). But I feel very strongly that ease of use of this API should be our first goal and so the enums shouldn't be single letters.
> 
> It also seems like we could take the longer names directly from the SAM spec:
> 
> letter	name
> M	alignment_match
> I	insertion
> D	deletion
> N	skipped_region
> S	soft_clipping
> H	hard_clipping
> P	padding
> =	sequence_match
> X	sequence_mismatch
> For anyone who is very familiar with that spec, it seems like they would be also be familiar with the longer names.
> 
> —
> Reply to this email directly or view it on GitHub.
> 




-- 
 The Wellcome Trust Sanger Institute is operated by Genome Research 
 Limited, a charity registered in England with number 1021457 and a 
 company registered in England with number 2742969, whose registered 
 office is 215 Euston Road, London, NW1 2BE.