1794-dev-ontosealevel

[YiKaiTsai]

There a few issues/concerns that require attention. @sm453 , would appreicate your inputs, thanks.

1) Currently, there is a SeaLevel concept and a SeaLevelMeasurement concept. The intention is that a sea level (say global mean sea level or Singapore mean sea level) can have different measurements at different date and time. Instead of instantiating different instances of SeaLevel each time we measure the global mean sea level or Singapore mean sea level, we have one instance of SeaLevel to represent the concept of the global mean sea level or Singapore mean sea level, then different instances of SeaLevelMeasurement to represent the sea level measured at different time. And then om:Height is linked to SeaLevelMeasurement. @sm453, would appreciate your thoughts on whether this would be the good practice or om:Height is to be linked to SeaLevel and SeaLevelMeasurement to be removed?

2) Currently, the concept of Damage due to rising sea level is incorporated into OntoSeaLevel, and is linked directly to SeaLevelMeasurement via hasImpact. I feel that there is a better way to represent this.

For example, we could have a concept called SeaLevelRise, perhaps in OntoSeaLevel or a new ontology called OntoSeaLevelRise. Then, one could have SeaLevelRise link to a SeaLevel, and have a starting SeaLevelMeasurment and an ending SeaLevelMeasurement. Then, the Damage concept can be linked to the SeaLevelRise concept via hasImpact and will no longer link to SeaLevel.

Please see the Miro board for a visual illustration. See the frame ‘2nd draft’ for the current OntoSeaLevel draft in this pull request. See the frame ‘potential 3rd draft’ for the illustration of the above comment in 2) regarding a possible SeaLevelRise concept.

[sm453]

1. Currently, there is a SeaLevel concept and a SeaLevelMeasurement concept. The intention is that a sea level (say global mean sea level or Singapore mean sea level) can have different measurements at different date and time. Instead of instantiating different instances of SeaLevel each time we measure the global mean sea level or Singapore mean sea level, we have one instance of SeaLevel to represent the concept of the global mean sea level or Singapore mean sea level, then different instances of SeaLevelMeasurement to represent the sea level measured at different time. And then om:Height is linked to SeaLevelMeasurement. @sm453, would appreciate your thoughts on whether this would be the good practice or om:Height is to be linked to SeaLevel and SeaLevelMeasurement to be removed?

Sounds to me like any sea level should be a standard time series, but the way you talk about it suggests that isn't currently your plan? I'm guessing this would solve all the issues you mention. Also, this would have the added advantage that you could use the Forecasting Agent to create forecasts, and you wouldn't need to reinvent any wheels how to represent this ontologically (because this has already been done).

[sm453]

2. Currently, the concept of Damage due to rising sea level is incorporated into OntoSeaLevel, and is linked directly to SeaLevelMeasurement via hasImpact. I feel that there is a better way to represent this.

For example, we could have a concept called SeaLevelRise, perhaps in OntoSeaLevel or a new ontology called OntoSeaLevelRise. Then, one could have SeaLevelRise link to a SeaLevel, and have a starting SeaLevelMeasurment and an ending SeaLevelMeasurement. Then, the Damage concept can be linked to the SeaLevelRise concept via hasImpact and will no longer link to SeaLevel.

For starters, I'd call it "change" rather than "rise", for generality. I believe it should simply point to two entries in a sea-level time series (the "start" and "end" of the delta). This would then contain all necessary information (the times over which the change is considered, and the start and end values of the sea level). You could then associate any damage to an instance of such a SeaLevelChange.

Whether such a design is politically a good idea is a different question... I would expect that this will expose a large attack surface, e.g. people will question whether any particular damage is really attributable to a certain change, and over what period this should or should not have been considered...

[YiKaiTsai]

Sounds to me like any sea level should be a standard time series

Yeah. I have updated accordingly.

believe it should simply point to two entries in a sea-level time series (the "start" and "end" of the delta).

Makes sense. Only thing is that I am not sure how this should be represented in the ontology. As the time series is actually stored in PostgreSQL, and OntoTimeSeries does not have any concept that represents an entry in the time series.

[sm453]

If sea level is represented as time series, does the measuredIn relationship it still make sense? Is this not already captured by the time series?

[sm453]

believe it should simply point to two entries in a sea-level time series (the "start" and "end" of the delta).

Makes sense. Only thing is that I am not sure how this should be represented in the ontology. As the time series is actually stored in PostgreSQL, and OntoTimeSeries does not have any concept that represents an entry in the time series.

Use time stamps (with which you can then look up in the time series)?

[YiKaiTsai]

One thing to note is that TBoxGeneration could not generate the range in the OWL file for the data properties, hasStartTime and hasEndTime, even though their range is defined in the CSV file. The range in the OWL file for these two data properties had to be manually inputted.

[sm453]

One thing to note is that TBoxGeneration could not generate the range in the OWL file for the data properties, hasStartTime and hasEndTime, even though their range is defined in the CSV file. The range in the OWL file for these two data properties had to be manually inputted.

Ok, in that case, can you please add a README.md file that contains exactly that explanation? (so that when the next person edits the CSV file and regenerates the OWL there won't be any surprises...)