validate mappings for transformations

[rapw3k]

please double check mappings of LUCAS and SRDB. THey are in the transformations folder. With LUCAS there were some cases with mismatches in the units of measurements. Also not sure about some of the properties used.

[rapw3k]

@ldesousa pleae accept invitation to the repository ( i cannot assign this to you)

[ldesousa]

I just committed new versions of the CSVs with notes on unit conversions. For Lucas everything looks good, except for Potassium, because of the conversion from grams to moles. I will follow up on it with Johan.

For SRDB there are still questions with glosis_lh:bulkDensityWholeSoilProperty, glosis_pr:SoilClassificationWRB, glosis_lh:bulkDensityWholeSoilProperty and glosis_cm:soilDepthProperty. I will follow up on this with SRDB. But you can go forwards with the other properties, texture, etc.

[ldesousa]

Opened a new issue at the SRDB repository with these questions: https://github.com/bpbond/srdb/issues/138

[rapw3k]

@ldesousa please check my updates in lucas mapping. i added the observed property and the procedure if provided. In many cases we have possibility in Glosis to specify procedure but we dont know the used one in LUCAS, maybe you know? Please check

• PH Issue (see ticket 65)
• Carbonates content class used
• Phosphorus content, how to get % I made a comment
• in general for all those conflicted unites, i use the one from LUCAS not from ontology

[rapw3k]

issue in srdb is answered. please double check mapping file

[ldesousa]

I just updated the CSVs with a few notes (via https://github.com/rapw3k/glosis/commit/ccf0c20124457d799a99748c107734970745c8d5). Here below some more details.

LUCAS:

• Carbonates content: use glosis_lh:TotalCarbonateEquivalent, because you have a numerical result
• Extractable potassium content: the only work around is to create a new observation and a new result for the same property, using cMOL/kg as unit. Open an issue and assign it to me if you wish me to create it.

SRDB:

• dont use the Soil_type field, since it can be anything in the source;
• dont use C_soildepth as it does not correspond to any of the properties in GloSIS (and its definition is too loose to be useful);
• bulk density assumed to be always whole soil.

[rapw3k]

regarding PotassiumExtractableElementsValue, see https://github.com/rapw3k/glosis/issues/67 . I would just delete the CentiMOL per KG constraint from value. let me know what you think

[rapw3k]

regarding SRDB I would create another more general observation, we have SoilClassificationWRB, SoilClassificationFAO, SoilClassificationUSDA lets just create "SoilClassificationAdHoc" or "SoilClassificationOther", with observed property "SoilClassificationAdHocProperty" "SoilClassificationOtherProperty" and hasSimpleResult a string

[ldesousa]

regarding PotassiumExtractableElementsValue, see #67 . I would just delete the CentiMOL per KG constraint from value. let me know what you think

I think that would go against SOSA/S&M, the observation instance must always declare a unit. At least that is my understanding.

[ldesousa]

regarding SRDB I would create another more general observation, we have SoilClassificationWRB, SoilClassificationFAO, SoilClassificationUSDA lets just create "SoilClassificationAdHoc" or "SoilClassificationOther", with observed property "SoilClassificationAdHocProperty" "SoilClassificationOtherProperty" and hasSimpleResult a string

A soil classification without a reference to a classification system does not provide useful information and can easily lead to misinterpretation. We can later evolve the ontology to consider local/regional systems, but in a way that requires users to always declare a reference to the concerned system.

The problem with SRDB data is that it can report to different systems or even to no particular system. There is no simple way around it from a semantic point of view.

[rapw3k]

but the ontology has the constraint (in the parent class PhysioChemicalValue ) that the observation instance must declare a unit.: http://qudt.org/schema/qudt/unit only http://qudt.org/schema/qudt/Unit

We just would remove the constraint that says which specific unit it must be used: http://qudt.org/schema/qudt/unit value http://qudt.org/vocab/unit/CentiMOL-PER-KiloGM

[rapw3k]

regarding SRDB I would create another more general observation, we have SoilClassificationWRB, SoilClassificationFAO, SoilClassificationUSDA lets just create "SoilClassificationAdHoc" or "SoilClassificationOther", with observed property "SoilClassificationAdHocProperty" "SoilClassificationOtherProperty" and hasSimpleResult a string

A soil classification without a reference to a classification system does not provide useful information and can easily lead to misinterpretation. We can later evolve the ontology to consider local/regional systems, but in a way that requires users to always declare a reference to the concerned system.

The problem with SRDB data is that it can report to different systems or even to no particular system. There is no simple way around it from a semantic point of view.

I agree with you; however, we should also be flexible. There is a trade-off of how formal and how flexible we define our model. At the end of the day even if the classification does not conform to any specific reference system, it is still useful from my point of view. Such information can still be captured, and queried in the knowledge base.

[ldesousa]

@rapw3k I corrected the units for Total and Extractable elements this morning, now in tag v1.0.3. Moments ago I pushed a new version of the mappings spreadsheet.

For reference, here is the reasoning on the units:

PERCENT = dag/kg 1 kg = 1 000 000 mg 1 dag = 10 000 mg 1 000 000 mg/kg = 100 dag/kg = 100 %

[ldesousa]

Mappings are done at the moment. If more are necessary, new issues can be opened.