Should we prefix the digests that we return from seqcol?

[nsheff]

In issue #37 we raised the point of "to prefix or not to prefix", but there were really 2 issues being discussed there:

1. Should seqcol prefix digests that become part of the seqcol representation that is digested?
2. Should seqcol prefix the seqcol digests it generates? And should it require these for queries?

Issue #37 discusses the first issue, which we decided and posted an ADR for (the upshot is we don't add anything specifically, but if an external protocol like refget specfies that such and such prefix is actually part of the identifier, then clearly we just take that at face value).

This issue is meant to track the 2nd point: Should seqcol prefix the seqcol digests it generates? And should it require these for queries?

what do we want to accept in the API? with or without prefixes?
what does the server serve? the output provided to the user. Do we have to say that these strings have to be prefixed with something? When we return things, do we include these prefixes? Or do we make it user-controlled through query parameters or something?

My current thinking is that the answer should be No.

I think we should never add or expect prefixes. They are for entities that surround the spec, not for the spec itself.

[waterflow80]

I was just wondering, are we talking about the SQ. prefix or about the ga4gh: prefix for the sequences digests (which I think was resolved here in PR #42) ?

And I was also wondering whether the SQ. prefix is a part of the ga4gh checksum algorithm, as mentioned in the refget spec, or it's a Refget required prefix to retrieve ga4gh digested sequences ?

[nsheff]

are we talking about the SQ. prefix or about the ga4gh:

Both.

And I was also wondering whether the SQ. prefix is a part of the ga4gh checksum algorithm, as mentioned in the refget spec, or it's a Refget required prefix to retrieve ga4gh digested sequences ?

I believe it is: 1) not part of the checksum algorithm, but 2) it is a refget required prefix to retrieve ga4gh digested sequences.

[nsheff]

A year later, where we've come on this:

I believe we've come to agreement that we should neither prefix responses returned, nor expect prefixes on queries sent to the server. The idea of these kinds of prefixes are external to this spec, and should therefore be handled by the external service or environment or context in which this spec is used (eg the greater ga4gh ecosystem as a whole).

[tcezard]

I wanted to revive this question as we're starting to incorporate sequence collection into other standards.
In order to separate Sequence collection digests from other GA4GH digest they will need to be prefixed and name spaced.
We all agreed that TASC should be making the final decision on the prefix assigned to and entity but we should discuss and agree on a proposal here:
The current proposal is:

• name space: ga4gh
• type: SC
  Which would give a fully qualified identifier of ga4gh:SC.ucvvsklhda834nsdnskdsjs56dadsa where ucvvsklhda834nsdnskdsjs56dadsa is a level 0 sequence collection digest

Are there any disagreement with this proposal?

[tcezard]

We also had a short discussion last meeting about the possibility of referencing level 1 digest externally and if yes how they should be prefixed.
Could of idea were thrown around:

• use a different type like S1
• use some for of subtype like SC.1

I'm not sure if any of these solution are satisfactory though.

[sveinugu]

We also had a short discussion last meeting about the possibility of referencing level 1 digest externally and if yes how they should be prefixed. Could of idea were thrown around:

• use a different type like S1
• use some for of subtype like SC.1

I'm not sure if any of these solution are satisfactory though.

My suggestion is to use the name of the attributes to define a tree, e.g.:

ga4gh:SC.sequences.GD6aj3...

In addition to being self-describing, it also opens up for describing level 2 digests, should that ever be needed.

[sveinugu]

My suggestion is to use the name of the attributes to define a tree, e.g.:

ga4gh:SC.sequences.GD6aj3...

In addition to being self-describing, it also opens up for describing level 2 digests, should that ever be needed.

One contra-argument is that such identifiers might become rather long. But we can always later define aliases to common level-1 digests, such as e.g. GA4GH:SC.CS.Yb2Hc... as an alias to GA4GH:SC.name_length_pairs.Yb2Hc... for coordinate systems. So one way of solving this is to say that you can always describe attribute values/digests using the lowercase attribute names, while we reserve the right to define uppercase aliases for commonly used digests.

This is in any case an advantage of our choice to exclude the prefixes from the digest algorithm - it's all external and just something we need to agree on.

[tcezard]

My suggestion is to use the name of the attributes to define a tree, e.g.:
ga4gh:SC.sequences.GD6aj3...

I think this would work as an identifier as it guarantees uniqueness however it's not clear to me how it would work from a resolver point of view.
My understanding of the resolution path for level 0 identifier ga4gh:SC.ucvvsklhda834nsdnskdsjs56dadsa would be something like:

1. identifiers.org resolve ga4gh to GA4GH resolver
2. GA4GH resolves SC to Sequence collections servers collection endpoint
3. Sequence collection server resolve ucvvsklhda834nsdnskdsjs56dadsa

for a level 1 ga4gh:SC.sequences.GcvcduyYdfwLVXZerYRejhGdaj3 the resolution path seems less clear

1. identifiers.org resolve ga4gh to GA4GH resolver
2. GA4GH resolves SC to Sequence collections servers collection endpoint
3. Sequence collection server needs to support resolution of sequences.GcvcduyYdfwLVXZerYRejhGdaj3 to the attribute endpoint or the list endpoint.

Or

1. identifiers.org resolve ga4gh to GA4GH resolver
2. GA4GH resolves SC.sequences to Sequence collections servers list endpoint or attribute
3. Sequence collectionserver resolve GcvcduyYdfwLVXZerYRejhGdaj3.

In both case the sequences part of the identifiers needs to transfer from to the endpoint path
/attribute/seqcol/sequences/GcvcduyYdfwLVXZerYRejhGdaj3
or
/list/seqcol?sequences=GcvcduyYdfwLVXZerYRejhGdaj3