schema-revision: elements/annotationFile.schema.json

[lzehl]

1. rename property or schema annotationFile
   • property: definedIn, schema: annotationFile or annotationStorage ?

[UlrikeS91]

Not sure what you are asking exactly. Adding definedIn here makes sense as an optional property to be able to point to the original file the annotation comes from.

I agree that one of the annotationFile parts should be renamed to make it less confusing. If we were to rename the schema to annotationStorage, I would intuitively expect that you can point to a repository where one or several annotation files are located. The way the schema is built at the moment, this is not the intention, right? If not, I would prefer to keep annotationFile as schema name and e.g. annotationFileStorage or fileStorage as the property name.

If that's not what you asked for, could you explain in more detail what you are wondering about? :)

[lzehl]

Feel free to follow my thoughts that let me to it, but the important suggestion comes at the end of this comment.

I thought about it a bit more and I suggest not to introduce another property name to point to a fileInstance.schemas.json, but stick to the one we typically use which is definedIn. In this case there is no name conflict with the schema annotationFile. Alternatively I could imagine a property storedIn or representedIn instead of definedIn.

The original file (fileInstance.schemas.json) where the annotation was inspired from is pointed to in the annotation.schema.json via the property inspiredBy.

More points to discuss here:

2. should we move annotationFile.schemas.json to core or to options ?

3. I would like to move the navigationRules from annotation.schemas.json to annotationFile.schemas.json and probably add a referenceSpace property here as well.

   • reasons:
     • the annotationFile.schemas.json points to the actual file that contains the annotation for display
     • although the annotation could have it's own native space (space from file in inspiredBy), it might be delivered in several other spaces (each annotationFile space)
     • since we do not want to cover full provenance in SANDS, I would suggest to define one annotation based of the inspiredBy, but then group all representations of this annotation (if there are multiple ones)
   • in order to display each representation of an annotation within the corresponding file correctly the viewer team would need to know:
     • the navigationRules
     • the referenceSpace
     • the internalFileIdentifier

More concrete example for point 3)

• each Julich-Brain annotation (left&right hemisphere) are made in 10 subjects, but we do not have access to the individual data
• those annotations build the probability map of one area to which we have access to in two different coordinate spaces (colin27 & mni152)
  • in SANDS I would now create for each hemisphere an annotation for the probability map of one area with no inspiredBy and two annotationFiles, one for each coordinate space OR to simplify the atlas registration I would not create annotations for the probability maps but only the maximum probability map of each area (which should be default representation of the parcellation of the atlas):
• the maximum probability map of an area is constructed from all the pms of all (surrounding) areas
  • in SANDS I would now create for each hemisphere an annotation for the max probabiliy map of one area with inspiredBy linked to (at least) the probability map of that area (both coordinate spaces) and two annotationFiles, one for each coordinate space that links to the maximum probability map with the internalFileIndentifier for that area
  • in this case the inspiredBy actually depends on the coordinate space, but creating in total 4 annotations for one area (one for each hemisphere + each coordinate space it is represented in) seems to be too cumbersome and repetitive...

What if we move also the inspiredBy with the nativeCoordinateSpace (optional) into the annotationFile? Here a complete revised suggestion:

• annotation
  • criteria [expects: protocol|protocolExecution]
  • criteriaType [ expects: asserted|processive]
  • annotationFiles [expects: annotationFile]: (I nest the schemas now here for simplicity)
  • displayIn [expects: image]: (I nest the schemas now here for simplicity)
    • definedIn [expects: fileInstance]
    • axes [expects: axes]
    • coordinateSpace [expects: coordinateSpace]
  • inspiredBy [expects: image]: (see displayIn for schemas)
  • navigationRules [expects: navigationRules]: (I nest the schemas now here for simplicity)
    • internalFileIdentifier
    • centralCoordinate [expects: coordinate]
    • viewPoint ? (this is not yet clear, but we wanted to define e.g, also the camera angle...)

@UlrikeS91 @aeidi89 @skoehnen @tgbugs What do you think?

[lzehl]

Based on the discussions in #27 this schema needs to be merged with annotation schema also discussed in #27

[lzehl]

was merged into annotation. PR already integrated