For this Issue, there are two separate aspects of the specification that I want to try to disentangle, as it becomes pertinent for the way in which we build this BEP.
I'm going to start with this example from common imaging derivatives:
Probabilistic Segmentations
Probabilistic segmentations of brain tissue represent a single anatomical structure with values ranging from 0 to 1 in individual 3D volumes or across multiple frames.
If a single structure is included, the label entity SHOULD be used to specify the structure.
Here I want to separate the filesystem naming convention, i.e. "_probseg", from what is in the current state of the BEP named the "data representation". In the example case here, this would be an image of floating-point data type where values are constrained to lie in the range [0.0, 1.0].
On first inspection this may seem like an unnecessary disambiguation. I propose however that it becomes a problem for structuring the specification when either:
The descriptions of such "data representations" become exceeding complex; e.g. in BEP016 we not only have many possible data representations for encoding orientation / anisotropic information, but some of these in turn necessitate lengthy descriptions (e.g. the spherical harmonics convention used for representing continuous ODFs).
A non-trivial data representation is applicable to multiple distinct items in the specification. E.g. Imagine that BEP016 were merged, but there were then some other derivative extension that used spherical harmonics data. It would not be appropriate for the SH description to appear in one derivative location and then be referenced in the other derivative.
It would instead be more appropriate for there to be some form of centralised dictionary of such representations to which many locations in the specification may refer. This might e.g. be in the Appendix.
(As mentioned elsewhere, BEP016 has the prospect of setting multiple precedents that will be applicable to many other BEPs, so we want to get these decisions right first time if possible)
92 has already done a certain amount of reorganisation, and demonstrative examples have all been placed at the end of the page. It is possible that further reorganisation might happen, for instance moving the SH definition (#100) or removing the demonstrative examples entirely in favour of actual data (#34). I think those can be discussed on a per-topic basis, and so this older Issue is no longer beneficial.
Lestropie
commented
4 months ago
For this Issue, there are two separate aspects of the specification that I want to try to disentangle, as it becomes pertinent for the way in which we build this BEP.
I'm going to start with this example from common imaging derivatives:
Here I want to separate the filesystem naming convention, i.e. "
_probseg", from what is in the current state of the BEP named the "data representation". In the example case here, this would be an image of floating-point data type where values are constrained to lie in the range [0.0, 1.0].On first inspection this may seem like an unnecessary disambiguation. I propose however that it becomes a problem for structuring the specification when either:
The descriptions of such "data representations" become exceeding complex; e.g. in BEP016 we not only have many possible data representations for encoding orientation / anisotropic information, but some of these in turn necessitate lengthy descriptions (e.g. the spherical harmonics convention used for representing continuous ODFs).
A non-trivial data representation is applicable to multiple distinct items in the specification. E.g. Imagine that BEP016 were merged, but there were then some other derivative extension that used spherical harmonics data. It would not be appropriate for the SH description to appear in one derivative location and then be referenced in the other derivative.
It would instead be more appropriate for there to be some form of centralised dictionary of such representations to which many locations in the specification may refer. This might e.g. be in the Appendix.
(As mentioned elsewhere, BEP016 has the prospect of setting multiple precedents that will be applicable to many other BEPs, so we want to get these decisions right first time if possible)