Open adbartni opened 6 months ago
Discussing in Jan 22 call: Issue is degree to which OBI wants to take on MRI specific data properties. Is it possible for MRIO to enhance OBI classes with these properties? The specificity of modelling creates a challenge for OBI. But we're aware that this is an incentive for adding them to MRIO directly... but this runs the risk of maintenance issues in the MRI domain in the future? Can you comment on ability to define data properties on your side, after reusing OBI MRI classes in MRIO?
After discussion on Jan 29 OBI call, MRIO developers will submit generic versions of the subclasses of 'magnetic resonance imaging assay' class to OBI that do not rely on the MRIO data property axioms but do include additional information in their textual definitions that capture some of the information in the MRIO logical axioms.
@addiehl - checking in on the status of this?
This will be coming in the next couple months.
Hello, and thank you for your cooperation in incorporating many of our MRI classes into OBI thus far (#1481). We have several more classes we would like to contribute, mostly pertaining to the acquisition of MRI data. These are subclasses of
magnetic resonance imaging assay
and largely correspond toimage data set
subclasses that have already been added to OBI. For example, a proposed classT1 weighted imaging acquisition sequence
has as specified outputT1 weighted image data set
(OBI:0003341).Below is a screenshot from Protege of the structure of MRI acquisition terms we would like to contribute:
Unlike the
image data set
classes that we have already integrated with OBI, these image acquisition assays use logical axioms to describe the parameters keyed into an MRI machine to acquire a specific kind of MRI data. These classes also use data properties that we have defined in MRIO to describe the process of acquiring MRI data. Below is a screenshot of Protege of an example of these properties used to define the acquisition of aT1 weighted image data set
.As such, we would like to discuss whether such specific classes are appropriate for OBI, or whether we should make them more generic at higher levels with the ability to create subclasses that use specific data properties.
We would be happy to discuss during the OBI developer meeting. Thanks! Alex Bartnik and Alex Diehl