MixtureDesign Mapping

[alFrie]

With the e-module mapping script almost finished, I'll start writing the mapping script for the mixture design now.
Tasks:

• Edit the metadata exctraction script: Match the keys to placeholders
• Map the metadata in the yaml-file to the ontology by replacing placeholders.
• Write a test.

[alFrie]

First question: Is this Date given in the top right also the Mixing_Date? Meaning was this file really created/filled out on the same day the mixture was done? It differs from the name of the xlsx-file. (Example 2014_08_05 Rezeptur_MI.xlsx has the date 30.6.14 as seen in the image).
Maybe @StephanPirskawetz knows the answer.

Also: The lab location is again BAM like with e-module or have the mixes been made at other locations?

[StephanPirskawetz]

It should be the mixing date. It might sometimes happen that they repeat a mixture, copy the file and forget to change the date. For these mixtures always BAM is the location.

[alFrie]

It should be the mixing date. It might sometimes happen that they repeat a mixture, copy the file and forget to change the date. For these mixtures always BAM is the location.

Great, thank you!

[alFrie]

The mixDesign-extraction produces a yaml-file that works with the new uploaded mixture-mapping-script. Please see for further discussion #139 .

[joergfunger]

Based on this discussion with @aradermacher and @cezary17 , an alternative structure of the mix design json would allow us to have a flexible number of mix components. Please see the attached two json files. It would first require to define all the materials that are used (e.g. the specific cement, water, ..), and in a second step that cement is then referenced in the list of ingredients with a specific amount in the mix.

MIX={
  'operator_date': '2014-12-10',
  'tester_name': 'Haamkens',
  'specimen_name': '8.2 (Wolf)',
  'water_cement_ratio': 0.5454545454545454,
  'water_effective--quantityinmix': 0.0,
  'water_effective--bulkdensity': 0.0,
  'water_effective--volume': 0.0,
  'air_content--quantityinmix': 0.0,
  'air_content--bulkdensity': 0.0,
  'air_content--volume': 20.0,
  'ingredients': {
    'cement_identifier': {
      'quantityinmix': 330.0,
      'volume': 106.5
    },
    'water_total_identifier': {
      'quantityinmix': 180.0,
      'volume': 180.0
    },
    'admixture_identifier': {
      'quantityinmix': 4.95,
      'volume': 4.3
    },
    'aggregate_identifier': {
      'quantityinmix': 1720.0,
      'volume': 656.2
    }
  }
}

INGREDIENTS=[
  {
    'cement_identifier': {
      'bulkdensity': 3.1,
      'annotation': 'CEM I 32.5 R Zementwerk Berlin',
      'ingredient_type': 'cement'
    }
  },
  {
    'water_total_identifier': {
      'bulkdensity': 1.0,
      'ingredient_type': 'water_total'
    }
  },
  {
    'admixture_identifier': {
      'bulkdensity': 1.14,
      'annotation': 'FM 21/BV 21',
      'ingredient_type': 'admixture'
    }
  },
  {
    'aggregate_identifier': {
      'bulkdensity': 0.0,
      'ingredient_type': 'aggregate'
    }
  }
]

[alFrie]

Based on this discussion with @aradermacher and @cezary17 , an alternative structure of the mix design json would allow us to have a flexible number of mix components. Please see the attached two json files.

Thanks, I will look into it once the test files for emodule are finished.

--

For now this branch won't need to develop the mapping script, since we will be using a generic mapping script, see #118 (comment)
Meaning, on this branch we now only need to focus on the metadata extraction and the tests.

Update: We develop all extraction and mapping scripts on #117