Units for experimental Young's modulus data

[eriktamsen]

While working on the calibration PR, I had a look at the extracted experimental data for the Young's modulus test. The units are part of the name of the columns in the CSV file. This is not ideal, or usable. As I have lost the overview of what is happening in which branch and issue, I am not sure if this has already been adressed. As far as I can remember, all relevant fields in the ontology have units linked. I assume therefore the data extraction script needs to be improved, to solve this, so that the units are availiable in a machine readble format. I would suggest to add them to the metadata yaml (or json if that has been changed). It is possible, that the units dont change as our data extraction is only for one specific machine. If this is the case, this would still require the information to be availiable. Meaning, e.g. just hard coding this data in the meta data file.

@AidaZt, @ThiloMuth, @StephanPirskawetz: Please check if any change is required and if so, make a plan of how to best implement this.

[AidaZt]

There is no placeholder currently in knowledge graph templates to store the information of the units. This ones mentioned in #118 , I think Alina is looking into it. @alFrie right?

[eriktamsen]

Then there are two independent steps to be done

• [ ] include the units in the ontology / the placeholder in the KG
• [ ] improve the extraction script to save the values in a file

[alFrie]

There is no placeholder currently in knowledge graph templates to store the information of the units. This ones mentioned in #118 , I think Alina is looking into it. @alFrie right?

Correct, there are no placeholders for units.

[alFrie]

As far as I see it we have four options:

1. Extract units via metadata extraction, save them raw in json, map them raw to the KG
2. Extract units via metadata extraction, save them raw in json, convert & map them via mapping script
3. Extract and adjust units via metadata extraction, save then in json, map them to the KG
4. Extract and adjust units via metadata extraction, save then in json, not map them to the KG but give maybe a single placeholder saying we use IS base units or whatever

Could you just chose one of them or mention another if I forgot an option? @eriktamsen @joergfunger

Edit: And another question, the validation of the units, if they make sense and so on, is then part of the Shacl validation and not the extraction/mapping, right?

[joergfunger]

not sure I understand 1/2/3, 4 is not optimal. From my point of view, the unit should always be in the metadata.json (in case this is existing in the raw data, then use that value, if it is not there, we will fix this within the metadata extraction script which is specific to a defined raw file with an implicit assumptions on what units have been used). Then we will map the units similar to all other metadata files in the KG templates.

[alFrie]

What I ment with raw units/ converted units is that the original script by Ilias contained a function to check f.e. lengths above 100 and assuming then that the unit is cm and converting it to m and so on.

[joergfunger]

I think this automatic conversion creates more problems than it solves. I would rather have an error message (e.g. in the SHACL validation when certain assumptions (see above) are not fulfilled.

[alFrie]

That means you would prefer option 1: extract the units like they are given (raw) and map them raw to the KG, later check in the SHACL validation if they make sense, right?

Edit: While units are given for the mix metadata in the xlsx files (meaning we could just hardcode the units in the KG for this case), there are none given for the specimen.dat ... what to assume in this case? And also hardocde it?

[alFrie]

So Aida and I just had a meeting with Mattheo and talked about the implementation of units in the template.  Two things that we talked about: 

1. Doesn't adding not-unified units affect the possibility to query? If I query for a 1kg heavy specimen, I might not find 1000g heavy specimen. This means that the units should be definitely unified.
2. It is not as easy to map units as it was with previous values, where we could just replace a placeholder with a value-string. Units in ontologies have their own category. It would be easier to pre-define in the template a unit for each instance. This would mean we could just keep mapping the non-converted data as it is, not change anything about the mapping script and later validate with shacl and if neccessary correct the value to fit the unit. Either way, it's your call @joergfunger and @eriktamsen . Please decide on a way of handling the units. 

[joergfunger]

1. is a valid point, but I think that could be handled afterwards or even in a query (I remember this discussion in the ontology playground, and there seem to be ways to handle that in the query). e.g. here and here. As such I would start with just specifying the unit, if we consider a conversion required we could still use e.g. pint for an automatic conversion in a later stage.
2. Why is that tricky to map the units? I understand that it is not just a string, but a link to an instance defined in in the PMD core, I guess the units are specified there. Then we just need a conversion function that maps a unit string (e.g. MPa) to the corresponding entity. An idea might be to use another sign (instead of $$ $$), or always specify the expected conversion - usually a string ($$string myvalue$$) or for units ($$unit MPa$$) in the templates, the first one just replacing the string myvalue (would work also for real data, int, since that is essentially a string in the ttl file) and the second one (with unit) calling a function that has as input a string (MPa) and as output the required URI of the MPa unit.

A predefinition is not optimal, because e.g. in the US, everyone is still using kpi (kilopond per square inch). If we force them to use a different unit, it just would not work.

[mattheokru]

To 2.

This could be a way to map units. Like Jörg suggested the placeholder just needs to be replaced with the correct unit (an example is in the picture of a pmd unit at the bottom). I could create a Table in which every unit is listed in correspondence to its pmd individual. Would this work?

[eriktamsen]

Whichever way the units will be integrated in the KG, we need to specify them in the extracted metadata.

[joergfunger]

I guess ns3:Q174789 is mm in PMD units (are they using qudt, or reinventing PMD units?). Why is the placeholder http://... and not just Diameter_Unit? And as you suggested, there could by a python function (with a table, e.g. a dict) that maps the string in the json file (key, e.g. N/mm2 or MPa) to the ns3:Q17478 (value in the dict). In order to know, that this function has to be used to transform the string, I suggested to either use different placeholder markers, e.g. # or have a "labeled" placeholder (see above). Just an update on how this could be integrated into the sparql query, there is a paper and a zenodo link with an example query that convert e.g. feet to m.

[mattheokru]

I think they are reinventing PMD units, however as I looked into the QUDT maybe we should use this Ontology for the units since it has far more units than the current PMD? The Placeholders for the Units have an http://... because I needed to create a dummy Individual, otherwise ontopanel Converter wouldn't let me export the Ontology with an Individual which doesn't fulfill the requirements (full URI) The Placeholders are currently $$ for the units, like the Values, but I will change them to ## (e.g ##SpecimenDiameter_Unit##)

[mattheokru]

In addition the QUDT already has a "dictionary" for the units: This would be http://qudt.org/vocab/unit/... and then the Unit found in the Instances listed under https://www.qudt.org/doc/DOC_VOCAB-UNITS.html (I'm not sure if this is relevant but they also have a Java Unit Conversion Library (https://github.com/qudtlib/qudtlib-java) )

[joergfunger]

@mattheokru Why is that different now for the placeholders for the units compared to the other strings. The others also do not have the https ...?

[alFrie]

I started working now on the conversion script, so it can be integrated into the mapping script. The script should change the value of keys containing the keyword "unit" from something like "g" to a "http://...." URI. I don't know what source I should now use for the information of how to convert. For example the QUDT dictionary includes second, but not gram (or at least I wasn't able to find it).

I could create a Table in which every unit is listed in correspondence to its pmd individual.

So I think this would be helpful.

[StephanPirskawetz]

Look for GM: http://qudt.org/vocab/unit/GM :)

[alFrie]

Looking at the units in the EModuleOntology.drawio.xml I have some questions:

1. There is a unit for CompressionForce and one for MeasuringGauge/Transducer. The connected value for those are actually just integers pointing to the index of a column in a dataset. Does it still make sense to give there a unit?

2. We have ExperimentDate, which is a DateTimeStamp and ExperimentTime, which is of type decimal and is ment to have a unit. Why do we differ between Date and Time and don't store it as one, or if we store it seperated, why are they of different types, one has a Unit and the other does not?

3. Is the unit of Measurement duration seconds?

[joergfunger]

Yes, it makes sense to give that a unit, since the unit of the raw data file (columns) has to be stored somewhere. Theoretically, they could also be added as metadata to the file, but I think adding it to the graph here makes more sense.

[joergfunger]

DateTimeStamp is probably the starting point, and ExperimentTime is the duration of the experiment (the offset). In the optimal setting, this information would be stored in the description of the classes in the ontology, such that questions like that are self-explaining. @StephanPirskawetz is that included? Both should have units, the first one including a complete date , the second one only a duration). As for the unit of duration, @StephanPirskawetz will have to answer that, but I think s is correct.

[alFrie]

ExperimentDate and -Time look like this: So I was just wondering why the time is not a date-time-stamp. Maybe @mattheokru can tell me, why the time is stored as decimal and not als timestamp? Also, is it possible to add descriptions to the classes, @mattheokru ? Edit: And I think it would be good to remove the placeholder for the unit of "ExperimentTime", because other than "MeasurementDuration" the ExpTime is not given in Seconds, but instead it is a real time, like extracted from a date-time-stamp.

Yes, it makes sense to give that a unit, since the unit of the raw data file (columns) has to be stored somewhere.

@StephanPirskawetz what is the unit for CompressionForce and for Transducer?

[eriktamsen]

@alFrie: Ich hoffe ich verstehe deine Frage an Stephan richtig. Die Daten, die im E-Modul Test der BAM aufgezeichnet wurden, also in den "specimen.dat", haben auch eine Zeile mit Einheiten (Zeile 15). Die können und sollten also auch direkt dort ausgelesen werden für die Metadaten. Die "Transducers" messen eine Verschiebung, in diesem Fall in mm. Die Kraft (CompressionForce) ist gemessen in Kilonewton.

[AidaZt]

@alFrie you can also check the units in ExampleDataCPTOMapping.xlsx from Mattheo, the one i sent you.

[mattheokru]

@alFrie The Experiment Date is the date and time the experiment took place (that's why this is a date time stamp), the Experiment Time is suppose the be the duration of the test (hence the unit seconds). The Measurement Duration was initially suppose to tell the time the measurement took place (linked the data with the time within the test), but since we linked an excel column for the compression force we should do the same for the measurement duration, however I'm not sure if this is really necessary for the Ontology? If not I would remove MeasurementDuration.

[mattheokru]

The desciption of the Classes/Individuals unfortunatly gets removed if you export or work with them in Ontopanel/drawio. You would have to import the Base ontologies into Ontopanel entitymanager to see the descriptions

[alFrie]

@mattheokru Okay, this is not what the metadata extraction script is doing. (This part of the code was not written by me!) It selects the following values:

Yellow Box = Measurement Duration Red Box = ExperimentDate AND ExperimentTime. The information in the red box gets splitted up in half and saved as those two variables.

And that was the reason why I am confused over the unit of the ExperimentDate/Time - it both is a datetimestamp. @joergfunger / @eriktamsen Which one is now the real "MeasurementDuration"? The yellow box in my image ("Zeit") or the column in Mattheo's image ("Laufzeit")?. This column would be part of the data, not the metadata, if I'm correct.

[alFrie]

Both should have units, the first one including a complete date , the second one only a duration).

@joergfunger And what is a unit of a date? You want something like "dd.MM.yyyy hh:mm:ss"? (The "date" has no unit placeholder by the way, only the "time" has one).

Also shouldn't we just keep date and time as one thing, as datetime, instead of saving it into two different instances?

[alFrie]

@alFrie: Ich hoffe ich verstehe deine Frage an Stephan richtig. Die Daten, die im E-Modul Test der BAM aufgezeichnet wurden, also in den "specimen.dat", haben auch eine Zeile mit Einheiten (Zeile 15). Die können und sollten also auch direkt dort ausgelesen werden für die Metadaten.

@eriktamsen Dann brauchen wir dafür aber extra Platzhalter, denn diese Units haben doch nichts mit den anderen Metadaten, sondern mit den Messdaten zu tun? Was für Platzhalter sollen das dann sein?

[StephanPirskawetz]

@alFrie: Ich hoffe ich verstehe deine Frage an Stephan richtig. Die Daten, die im E-Modul Test der BAM aufgezeichnet wurden, also in den "specimen.dat", haben auch eine Zeile mit Einheiten (Zeile 15). Die können und sollten also auch direkt dort ausgelesen werden für die Metadaten.

@eriktamsen Dann brauchen wir dafür aber extra Platzhalter, denn diese Units haben doch nichts mit den anderen Metadaten, sondern mit den Messdaten zu tun? Was für Platzhalter sollen das dann sein?

Diese MTS-Formate und Zeiten sind etwas eigen. Rot umrandet sind Datum und Zeit, zu der der Programmteil "Bediener Information gestartet wurde. Zeit davor ist die Zeit, die vergangen ist, seitdem das ganze Programm gestartet wurde. Nach gelb umrandet: Start des Programmteils Belastungsfunktion. Das ist die wichtige Zeit und die sollte in die Metadaten übernommen werden. Alles anderen Zeiten sind unwichtig, auch die rot und die gelb umrandete (wieder die Zeit, die seit dem Programmstart vergangen ist). Die Einheiten in Zeile 15 sind für die Zeitreihen in den nachfolgenden Zeilen und spaltenweise zugeordnet. Da, soweit ich verstanden habe, diese Rohdaten (hier noch) nicht beschrieben werden, können wir alles nach dem Datum ignorieren.

[alFrie]

Danke @StephanPirskawetz !

Die Einheiten in Zeile 15 sind für die Zeitreihen in den nachfolgenden Zeilen und spaltenweise zugeordnet. Da, soweit ich verstanden habe, diese Rohdaten (hier noch) nicht beschrieben werden, können wir alles nach dem Datum ignorieren.

So hatte ich das auch verstanden. Und wie gesagt gibt es dafür ja auch gar keine Platzhalter. Deshalb würde ich die Daten in der blauen Box / Zeile 15 nicht extrahieren.

Nach gelb umrandet: Start des Programmteils Belastungsfunktion. Das ist die wichtige Zeit und die sollte in die Metadaten übernommen werden.

Also die im neuen Bild grün umrandete Box ist nun die wichtige, ja? Willst du die als eine Variable (also Datum und Uhrzeit gemeinsam) oder getrennt als "ExperimentTime" und "ExperimentDate" wie bisher abgespeichert haben? Wenn alle anderen Zeiten, selbst die gelb umrandete, irrelevant sind, dann sollte die Instanz "MeasurementDuration" ja aus dem KnowledgeGraph gelöscht werden, richtig?

[StephanPirskawetz]

Danke @StephanPirskawetz !

Die Einheiten in Zeile 15 sind für die Zeitreihen in den nachfolgenden Zeilen und spaltenweise zugeordnet. Da, soweit ich verstanden habe, diese Rohdaten (hier noch) nicht beschrieben werden, können wir alles nach dem Datum ignorieren.

So hatte ich das auch verstanden. Und wie gesagt gibt es dafür ja auch gar keine Platzhalter. Deshalb würde ich die Daten in der blauen Box / Zeile 15 nicht extrahieren.

Nach gelb umrandet: Start des Programmteils Belastungsfunktion. Das ist die wichtige Zeit und die sollte in die Metadaten übernommen werden.

Also die im neuen Bild grün umrandete Box ist nun die wichtige, ja? Willst du die als eine Variable (also Datum und Uhrzeit gemeinsam) oder getrennt als "ExperimentTime" und "ExperimentDate" wie bisher abgespeichert haben? Wenn alle anderen Zeiten, selbst die gelb umrandete, irrelevant sind, dann sollte die Instanz "MeasurementDuration" ja aus dem KnowledgeGraph gelöscht werden, richtig?

Ja, grün ist wichtig! Ob gemeinsam oder getrennt weiß ich nicht. Es gibt als Datentypen allerdings nur "dateTime". Wenn man mit dateTime rechnen kann, was ich vermute, dann ist das besser. Wenn auch im Mix KG so ein dateTime vorkommt, kann man die vermutlich einfach voneinander abziehen und bekommt so das Probenalter zur Zeit der Prüfung. Das wäre praktisch. Ist mit getrennten Variablen wahrscheinlich schwieriger.

[StephanPirskawetz]

Danke @StephanPirskawetz !

Die Einheiten in Zeile 15 sind für die Zeitreihen in den nachfolgenden Zeilen und spaltenweise zugeordnet. Da, soweit ich verstanden habe, diese Rohdaten (hier noch) nicht beschrieben werden, können wir alles nach dem Datum ignorieren.

So hatte ich das auch verstanden. Und wie gesagt gibt es dafür ja auch gar keine Platzhalter. Deshalb würde ich die Daten in der blauen Box / Zeile 15 nicht extrahieren.

Nach gelb umrandet: Start des Programmteils Belastungsfunktion. Das ist die wichtige Zeit und die sollte in die Metadaten übernommen werden.

Also die im neuen Bild grün umrandete Box ist nun die wichtige, ja? Willst du die als eine Variable (also Datum und Uhrzeit gemeinsam) oder getrennt als "ExperimentTime" und "ExperimentDate" wie bisher abgespeichert haben? Wenn alle anderen Zeiten, selbst die gelb umrandete, irrelevant sind, dann sollte die Instanz "MeasurementDuration" ja aus dem KnowledgeGraph gelöscht werden, richtig?

P.S. "MeasurementDuration" aus dem KnowledgeGraph löschen.

[alFrie]

Okay, danke @StephanPirskawetz !

@mattheokru that would mean we need to

1. remove the "ExperimentTime" and the corresponding Unit,
2. as well as "MeasurementDuration" with it's unit from the Template;
3. also maybe rename "ExperimentDate" to "ExperimentDateTime".

[alFrie]

@StephanPirskawetz Der DateTime-stamp aus dem der Rezeptur enthält nur ein Datum. Das sollte doch dennoch helfen, oder? (Zeile 1).

[StephanPirskawetz]

Ja, wir können die Zeit einfach auf 12:00 Uhr setzen. Falls es wichtig ist (Prüfungen früher als nach 28 Tagen), muss die Zeit der Wasserzugabe mit angegeben werden.

[alFrie]

Quoting a message of myself https://github.com/BAMresearch/LebeDigital/pull/118#issuecomment-1540174317:

I will be gone until the end of May. Meanwhile, @AidaZt will work on the unit conversion script, that will take any metadata-file as input and replace all units ("mm", "kN", "g" and so on) through their respective proper ontology unit URI. For this task some dictionary will be needed (as discussed in the issue https://github.com/BAMresearch/LebeDigital/issues/153 .

See you end of May!

[eriktamsen]

Ja, grün ist wichtig! Ob gemeinsam oder getrennt weiß ich nicht. Es gibt als Datentypen allerdings nur "dateTime". Wenn man mit dateTime rechnen kann, was ich vermute, dann ist das besser. Wenn auch im Mix KG so ein dateTime vorkommt, kann man die vermutlich einfach voneinander abziehen und bekommt so das Probenalter zur Zeit der Prüfung. Das wäre praktisch. Ist mit getrennten Variablen wahrscheinlich schwieriger.

Also die grüne Box ist für uns auch wichtig.

Die Einheiten in Zeile 15 sind für die Zeitreihen in den nachfolgenden Zeilen und spaltenweise zugeordnet. Da, soweit ich verstanden habe, diese Rohdaten (hier noch) nicht beschrieben werden, können wir alles nach dem Datum ignorieren.

@StephanPirskawetz: Meiner Meinung nach ist das so nicht richtig. Für unsere Simulation müssen wir wissen mit welchen Einheiten wir arbeiten. Selbst wenn du sagt, dass die BAM Daten alle die gleichen Einheiten haben, dann sollte das aber trotzdem irgendwo maschinenlesbar hinterlegt werden. Warum sollte das nicht einfach teil der Metadaten sein?

[alFrie]

@mattheokru Hast du das hier gesehen und umgesetzt? Wenn ja, kann ich leider die geupdateten KGs nirgends finden.

@mattheokru that would mean we need to remove the "ExperimentTime" and the corresponding Unit, as well as "MeasurementDuration" with it's unit from the Template; also maybe rename "ExperimentDate" to "ExperimentDateTime".

[mattheokru]

@alFrie Ja sollte da sein. Da das alles etwas chaos war habe ich einen Branch erstellt für die KG's. So ist alles an einem Platz und nicht in verschiedenen Branches/Pull Requests verteilt. Das macht es einfacher den Überblick zu behalten. Der Branch ist hier: https://github.com/BAMresearch/LebeDigital/tree/Knowledge_Graphs_Update