create parcellation.ttl

[tgbugs]

• partonomy concept
  • specific partonomy concept
    • species, developmental stage, defining citation ???
    • entities

[tgbugs]

@MFSY There are two ways we could do this

1. put the individual root parcellation concepts in parcellation.ttl
2. put the individual root parcellation concepts in their own parcellation files and import them via parcellation.ttl

The only tradeoff I can see is that in order to get the metadata about a parcellation scheme you have to load the ontology file that defines that scheme.

Thoughts?

[tgbugs]

First pass can be seen here.

[MFSY]

Thank you Tom for this first version.
First of all, I’m afraid not to fully understand differences between:

• ‘brain atlas’ and ‘brain parcellation scheme’
• ‘brain region’ and ‘brain parcel’

In the following, I’ll consider them equivalent. I’ll be happy to have more details about their respective differences though.

Let see the three main questions I would like to see the ontology answer. That is to say the competency questions:

• Retrieve available brain parcellation scheme along with their metadata
• Retrieve available brain parcellation scheme for a given species
• Retrieve available brain regions for a given parcellation scheme

Answering the first question using the first version of the parcellation scheme ontology will require to only get direct subclasses of ilx:ilx_brain_parcellation_scheme_concept if we don’t want to maintain a list of brain parcellations files. The other subclasses correspond to brain regions. This sort of semantic should not be put in hierarchy depth I believe. I suggest then to separate the brain parcellation scheme and brain regions tanonomies as presented in the following picture:

Also, developemental stage vocabulary exists from what I can see in bioportal with this query
Is it possible to reuse an existing one or at least to create a light one ?

[tgbugs]

Thanks for the feedback. The short version is that I think the easiest way to meet all three competency questions is to create classes for information artefacts representing the atlases/parcellation schemes.

1. In our usage brain parcellation schemes are defined by brain atlases. They contain the terminology used by the atlas by lack the spatial information that accompanies it. Similarly, brain regions are defined only by a center of mass, do not have boundaries, and may be defined for more than one species. Brain parcels do have boundaries and are defined for a specific species and have a direct mapping to experimental data. (This is why I have made all parcellation scheme concepts subClassOf the same root, they all have direct mappings to the real world.)

2. Right now we are splitting the parcellations out into files, but as you point out, that is an arbitrary decision and we could put everything in the same file so we don't want our model to depend on which ontology file we put things in. As a result we do need information artifact classes that corresponds to the parcellation schemes and atlases. We still need to have a parent class for all the parcellation scheme concept roots otherwise we pollute owl:Thing. The question then becomes which class (the information artifact, or the parcellation concept) we place the parcellation scheme/atlas level information on. The properties such as version, release year, and defining citation refer to the atlas, however the developmental stage and species refer to the concepts (since atlas don't have developmental stages nor are members of species). Most of these issues are the result of trying to make the Allen mouse Brain atlas v2 concept a subClassOf both brain parcellation scheme and things that has_taxon.... I will create an updated version of what I mean with a figure similar to your own to illustrate what I mean more clearly.

3. We have developmental stages in the ontology at the moment, but I would be happy to use EFO and flybase's stuff. Not sure exactly what to do about P56, maybe leave that as an anntation property because modelling post natal day seems like it will get messy eg FB-DV level.

[tgbugs]

@MFSY The file I'm using to generate these is here.

[tgbugs]

Further implementation reveals a need to distinguish between atlases, the parcellation schemes they use (not all parcellation schemes have extant and linkable/citeable atlases, eg HCP2016), and the parcellation scheme concepts contained/defined by the parcellation scheme. @MFSY's version has this correct. If we really need to model the atlses themselves we can either add them as links to scicrunch registry resources (if they exist) or to ilx terms that hold metadata on published texts (eg paxinos).

[MFSY]

I agree to distinguish between atlases, parcellation schemes and brain parcels (parcellation scheme concepts). In the version I proposed above, there is no concept of atlases as you pointed it out but only parcellation schemes and brain parcels. The only reason I see to have atlases as concepts (in the context of BBP) is to link specific metadata to it as you mentioned: version, release date, ...
However, knowing that that a brain parcellation scheme is define by at most one atlas (am I right ?), I'll suggest to keep atlas metadata linked to brain parcellation scheme concepts. What do you think ? And what are the next steps to have the parcellation ontology finalized ?

[tgbugs]

@MFSY I've pushed version 2. I also attached an updated diagram. Basically all I did was make it so that the parcellation concept had the relationship to the species and developmental stage instead of the artifact. I am currently using the developmental stage identifiers defined in NIFSTD since EFO xrefs them and it will be more expedient that trying to do a full integration of EFO. I can also change the annotation/object properties if needs be.

For the competency questions, while we can't use a DL query to cross the isDefinedBy, scigraph has no problem traversing that edge with a neighbors query. We can get a complete listing of parcellation schemes from either the atlas root term or the parcellation concept root term. The following DL query returns all the parcellation concepts defined for mice 'Brain parcellation scheme concept' and definedForSpecies some NCBITaxon_10090, choosing direct subclasses prevents it from listing absolutely everything. With the ability to do these three things I think we satisfy our competency questions. Let me know what you think. Thanks!

[MFSY]

Thank you. This new version can be used to answer the competency questions. I was wondering where the "P 56" in "adult P 56" developmental stage goes ?

[tgbugs]

I suppose it could go in as a note or some other annotation property, maybe species specific developmental timepoint or something like that? P56 seems more like data than something we would want to make an explicit ontology class. Thoughts?

[MFSY]

It can goes in an annotation property, I think.

[MFSY]

I'm trying to check if the atlas we use in BBP-NIP are already available in the generated parcellations repository (here). I see that all brain parcel terms have two labels: ilx:parcellationLabel (original one) and rdfs:label (original label preceded by version information). I can see the usage of the version in parcel term's name (multiple atlas version can define the same brain parcel) but is it possible to use rdfs:label and some prefLabel from skos for that. The prefLabel being the label without version information.

[tgbugs]

From what I recall from my conversation with Sean I still need to get Paxinos 2009 rat in. Yes, I will change to skos:prefLabel.

[tgbugs]

Updated to skos:prefLabel and added Paxinos, though it is 'The Rat Brain in Stereotaxic Coordinates 6th Edition' which is from 2007, will need to check to see if that is really what you all are using.

[tgbugs]

This is in the master branch now. Just need to mint identifiers. As a note the UBERON:0000105 ! life cycle stage branch of uberon could be an alternative set of identifiers that we could use to model the developmental stage portion of this. We could create a couple of species specific stages to handle things like post natal day in mouse and rat that make use of data properties.

[cmungall]

ssSOs federated with uberon:

http://obofoundry.org/ontology/mmusdv.html
http://obofoundry.org/ontology/hsapdv.html

we have another 18 or so species

[tgbugs]

These look like they can provide a good complement to the traditional E*/P* that shows up in many atlases. Will be interesting to compare with the terminology used by individual parcellation schemes. Thanks!

[tgbugs]

Discussions from last week revealed that there is an additional level of abstraction here that we are not capturing explicitly, namely that the labels for a parcellation scheme, and the parcellation scheme are NOT the same thing. The parcellation scheme is the set of pairs of each label with the associated atlas artifact. Therefore we need to avoid prefixing the labels with the 'source' atlas artifact since there can be more than one atlas that uses the same labels.

Some potential solutions to this issue.

1. Issue new labels for every single atlas. This is bad because, for example, the Allen ontologies do not change identifiers between atlases since the labels do not change and 'conceptually' these areas have not really changed.
2. Add multiple isDefinedBy edges to the parcellation scheme parent artifact. This is a better option, but fails for cases where labels may be present in one atlas and not in another.
3. Treat the labels as we do now, but provide clear documentation that the atlas artifact also needs to be included as context.

[jgrethe]

Hi Tom - to handle that do you want to relate the parcellation label with a more global label as there maybe differing correspondences between parellation labels and the more global anatomical concepts? So you would end up with:
Atlas Artifact <---has--- Parcellation Label ---[Spatial Relation]---> Anatomical Label 1
|---[Spatial Relation]---> Anatomical Label 2
... |--- [Spatial Relation]---> Anatomical Label N

So stick with something similar to (3)...

[MFSY]

Hi Tom, I would suggest the following solution:

• Each new "Parcellation scheme artefact" defines (through isDefinedBy) a corresponding "parcellation scheme concept":
  -- for example "Allen Human Brain Atlas v2" would define "Allen Human Brain Atlas parcellation concept v2" and "Allen Human Brain Atlas v3" would define "Allen Human Brain Atlas parcellation concept v3"
• If a brain parcel label (let say "amygdalohippocampal area, parvocelluar part") is (re-) used across the two previous brain atlases then it becomes a subclass of both "Allen Human Brain Atlas parcellation concept v2" and "Allen Human Brain Atlas parcellation concept v3".

The previous solution along with the elimination of brain atlas version mention in brain parcel labels will allows to get the brain parcels defined by a specific brain atlas by getting the subclasses of the "parcellation scheme concept" it defines.

[tgbugs]

Just had a meeting with @jgrethe and @memartone and we encountered another use case which is to be able to add relationships between different versions of brain parcels that have the same labels but different atlas versions. For example if there is a change from one atlas version of MBA to the next we want to be able to flag that there was a change. Therefore it seems that we do indeed need to have explicit representation of the intersection between a parcellation label and an atlas.

One way to do this is as follows.

1. Convert our existing 'parcellation concept' classes into 'parcellation label' classes (e.g. MBA and HBA identifiers are explicitly modelled as labels since they have stable identifiers that are used across atlas versions).
2. Create explicit label + atlas identifiers with a structure that could look like

ilx:someParcellationRegion a owl:Class ;
    rdfs:subClassOf ilx:parcellationRegion ;  # ilx:parcellationRegion would be an anatomical entity
    ilx:definingAtlas ilx:someAtlas ;  # same atlas representation that we use right now
    ilx:parcellationLabel ilx:someParcellationLabel .  # renaming of our current parcellation concept classes

This gives us a way to explicitly bind labels and atlases and make assertions about any changes that occur between those bindings for different versions of atlases. This will allow us to maintain partonomies on the labels (perhaps a bit confusing) that are asserted to hold across all atlases as well as atlas version specific hierarchies (e.g. the ones extract from vector representations of atlases).

Thoughts?

[tgbugs]

Here is an enumeration of the different ways that parcellation schemes can/could be ingested.

labels	identifiers	atlases	example	solution
same across multiple atlases	none	multiple	paxinos	labels -> global, atlases -> global, intersection class if there is a partonomy
different across multiple atlases	none	multiple	paxinos?	labels -> global, atlases -> global, OP if there is a partonomy, OP used to map label classes to atlas classes
different across multiple atlases	local	multiple	waxholm	local -> global, atlases -> global, changes across versions as synonyms with annotations for synonyms per version OR different versions of the input file have indexes that live in different namespaces (which will confuse the users looking for labels?)
same across multiple atlases	global	multiple	allen	global, atlases -> global, have their own partonomy

[tgbugs]

When writing up the docs for parcellation schemes also include #122.

[tgbugs]

We may want a hierarchy for displaying regions on an interface (so that they are not just a flat list), which is not a 'proper' part-of relation. This might be true for partonomies defined only on labels (e.g. MBA) which are not borne out by the actual spatial structure of their corresponding atlas regions. BFO:0000050 could still be used for these, but it might be confusing since the atlas labels intentionally do not fit under the BFO schema.

[tgbugs]

Additional competency questions to help guide the modelling of terms sourced from spatial anatomical sources as opposed to purely semantic sources.

1. Should I use this semantic or parcellation label (or set of labels) to name my my atlas regions?
   • You should not use labels defined for a rat on a mouse. Therefore, if paxinos reuses atlas labels between the rat and mouse atlases, we will create a new set of labels for each species. We will not create a new set of labels for different developmental stages, that can be modelled ala uberon with 'existence begins during' and 'existence ends during'.
   • While you could use UBERON identifiers as the basis for your atlas, we would probably not recommend it because it will significantly distort the semantics. You could drag them all into your own namespace, if you wanted.
2. Since labels are just labels and in theory can be applied to anything how to we properly scope the concepts that our versions of the parcellation labels refer to?
   • Species (as mentioned above).
   • If a label is said to correspond to some semantic spatial region, that region must be wholely contained in some or all of the parcellation regions defined by the atlases across which that label is used.

[tgbugs]

Paxinos is nearly ready to go, I still need to sort out the issue with the layers and nuclei using the same numbers for abbreviations (sigh).

[tgbugs]

Plate number and friends as a pseudospatial way to report with slightly more information. This falls somewhere between coordinate system and terminology.