#159 Handling of composite attributes based on virtual columns ('??')

[paulopinheiro1234]

During the ingestion of SDD for study 1449, composite attributes based on virtual columns are showing up in the SDD viewer as a buggy "DASO" URI. This situation occurs in properties with compose attributes, and when one of the attributes composing the property is a virtual column.

[paulopinheiro1234]

Paulo and Chip have done tests of this issue with the SDD for 1449, and it is still unclear the exact condition for the virtual column to show up in the SDD viewer as a buggy DASO URI. This is going to be further investigated as Issue #153 has been addressed.

[chipmasters]

More details:
The modeling pattern I started with looks like this:

Column | Label | Attribute | attributeOf | Unit | Time | Entity | Role | Relation | inRelationTo | wasDerivedFrom
MSLrlTscore | Receptive Language: T score | ncit:C120401 | ??receptive_language |   | ??visit1 |   |   |   |   |  
MSLrlAgequiv | Receptive Language: Age Equivalent | hhear:00526 | ??receptive_language |   | ??visit1 |   |   |   |   |  
??receptive_language |   | cogat:03174 | ??child |   |   |   |   |   |   |  

Here we have two attributes MSLrlTscore and MSLrlAgequiv which are both derived from a common attribute, the "receptive language" of the child. I started by creating a single ??receptive_language intermediate attribute and made these derivations the attributeOf this common attribute (which is attributeOf ??child).

When I processed this SDD in HADatAc, it merged the "Age Equivalent" derived attribute with the "Receptive Language" attribute, but it did not merge the T-score attribute. This led to the DASO terms appearing in the SDD viewer in HADatAc.

Then I tried making two separate intermediate attributes in such cases, as below:

Column | Label | Attribute | attributeOf | Unit | Time | Entity | Role | Relation | inRelationTo | wasDerivedFrom
MSLrlTscore | Receptive Language: T score | ncit:C120401 | ??receptive_language1 |   | ??visit1 |   |   |   |   |  
MSLrlAgequiv | Receptive Language: Age Equivalent | hhear:00526 | ??receptive_language2 |   | ??visit1 |   |   |   |   |  
??receptive_language1 |   | cogat:03174 | ??child |   |   |   |   |   |   |  
??receptive_language2 |   | cogat:03174 | ??child |   |   |   |   |   |   |  

This worked, in that when I loaded this SDD into HADatAc, it merged both attributes with the respective intermediate attributes, and when I view the SDD in the viewer I do not see the DASO terms. Here is what I see in the log:

2020-07-09 15:01:05 [LOG] [Merged Attribute] : ??receptive_language1 ---> [MSLrlTscore, Receptive Language: T score, , ??visit1, ncit:C120401]
2020-07-09 15:01:05 [LOG] [Merged Attribute] : ??receptive_language2 ---> [MSLrlAgequiv, Receptive Language: Age Equivalent, , ??visit1, hhear:00526]

And here is what I see in the SDD viewer:

MSLrlAgequiv |   | ??child | [Human] | Mullen scales of early learning-receptive language Age Equivalent |   |   | ??visit1
MSLrlTscore |   | ??child | [Human] | Mullen scales of early learning-receptive language http://purl.obolibrary.org/obo/NCIT_C120401 |   |   | ??visit1

[paulopinheiro1234]

I believe there is a hash table mapping a virtual column to an attribute. If that is correct, a virtual column can only be mapped to one attribute. Creating two virtual columns as describe above addresses the problem. If these virtual columns are representing instance, the implementation is correct. Otherwise, we will need to rethink the way of implementing this kind of pattern.