Added transplant field to specimen_from_organism. Fixes #1531

[idazucchi]

Release notes

For specimen_from_organism.json schema:

• added transplant field

Why are these changes needed?

The new field is needed to clearly indicate whether the sampled tissue comes from a transplanted organ. This field was requested by the kidney Bionetwork.

Reviews requested

This is a minor schema changes, all DCP2 reviewers need to review

[amnonkhen]

Should versions.json be modified as well?

[amnonkhen]

Have you considered using an ontology term? sych as http://purl.obolibrary.org/obo/NCIT_C12981

[ESapenaVentura]

not a bad idea - Could live under the class that amnon mentions, although that means we may accept terms we don't expect there

[idazucchi]

the aim of the transplant field is to highlight if a tissue was sampled from a different donor. This has two implications:

1. the tissue has a different genetic background from other specimens from the same donor
2. the tissue can contain cells from both the transplant donor and the recipient. This is particularly important for a xenografts because some reads will need to be mapped to a different reference genome

The two terms Allograft and Xenograft convey enough information on the two points above.
The other terms in the ontology branch are subtypes of either, or possibly both since the description doesn't clearly state if the graft is done within the same species (Cadaveric Venous Graft, Organ Graft, Free Arterial Graft, Flap).
The terms under graft in some cases are specific for an organ part, but this information is already recorded at the specimen level in the organ and organ_part fields.
Most of the terms add context on the medical/surgical procedure, but don't add information that's relevant for the two points above and in most cases lack information on whether the transplant is an allograft or xenograft.

I'm against ontologising the field because I don't think that it would add a lot of useful information, but rather it would make distinguishing between allograft and xenograft less easy

[hannes-ucsc]

I'm against ontologising the field because I don't think that it would add a lot of useful information

As far as I understand it, the motivation behind ontologising a field is to eliminate the need for schema (and metadata) updates when terms are added or updated, and to avoid inconsistencies between the schema enum and any ontologies that might already exist now, or that might be added in the future.

but rather it would make distinguishing between allograft and xenograft less easy

We will ultimately solve this in Azul/Data Browser. Users will be able to search by an ancestor term and that search will return references to any descendant term. It might be a while until this is implemented but we should take the long-term view here unless there is a good reason not to.

[idazucchi]

It's true that ontologizing a field can help avoid future updates, but in this case I can't imagine what other field we might want to add. Either the transplanted tissue comes from the same species or it comes from a different one. There might be artificial prothesis but those don't have cells that can be sequenced.

but rather it would make distinguishing between allograft and xenograft less easy

search by an ancestor term won't enable users to distinguish xenograft from allograft because of the ontology's structure: all terms under graft are siblings and are not under either xenograft or allograft. It is necessary to use xenograft or allograft to specify explicitly if the donor and transplant recipient are from the same species

[hannes-ucsc]

Doesn't that mean that the ontology is broken? Shouldn't the ontology reflect the fact that grafts can be subtyped along two unrelated dimensions, one being the whether the source and target of the graft are from the same species and the other being what the tissue type of the graft source is? In fact, shouldn't the tissue type of the graft source be represented as a separate field, potentially reusing an existing ontology for tissue types?

Either way, I'll defer to the bioinformaticians among the reviewers of this PR. I'll wait with my approval until I see theirs, but I won't request changes on this subject either.

[NoopDog]

Hi @idazucchi, I feel this and all other fields should be ontologized if possible. We don't need to allow all values from the ontology. The graph restriction section should let us specify that we only accept Allograft and Xenograft and their children.

[Wkt8]

Hi @NoopDog there are some fields that are useful to be ontologized where we can get a lot of value from it (interoperability), but this field would offer minimal value for that same amount of work. Adding here that this field captures useful information in some papers that have already come up (kidney) and will be coming up for Wave 2 of the bionetworks papers.

[NoopDog]

Hi @Wkt8 is there extra effort to ontologize the field? Also, for my knowledge, why do you feel we will not have the benefit of interoperability in this case? Thanks! D

[ESapenaVentura]

Should versions.json be modified as well?

versions.json gets updated "automatically" before the merge - the update_log is used by the "release_prepare.py" script to apply the version increase to the affected schemas AND its dependencies (e.g. a module loaded may affect several type schemas)

[hannes-ucsc]

I assume this is being superseded by #1548 so I am closing it. If I'm wrong, please just reopen.