Closed YiKaiTsai closed 3 months ago
- Currently, there is a
SeaLevel
concept and aSeaLevelMeasurement
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 ofSeaLevel
each time we measure the global mean sea level or Singapore mean sea level, we have one instance ofSeaLevel
to represent the concept of the global mean sea level or Singapore mean sea level, then different instances ofSeaLevelMeasurement
to represent the sea level measured at different time. And thenom:Height
is linked toSeaLevelMeasurement
. @sm453, would appreciate your thoughts on whether this would be the good practice orom:Height
is to be linked toSeaLevel
andSeaLevelMeasurement
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).
- Currently, the concept of
Damage
due to rising sea level is incorporated into OntoSeaLevel, and is linked directly toSeaLevelMeasurement
viahasImpact
. 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 haveSeaLevelRise
link to aSeaLevel
, and have a startingSeaLevelMeasurment
and an endingSeaLevelMeasurement
. Then, theDamage
concept can be linked to theSeaLevelRise
concept viahasImpact
and will no longer link toSeaLevel
.
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...
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.
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?
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)?
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.
One thing to note is that TBoxGeneration could not generate the range in the OWL file for the data properties,
hasStartTime
andhasEndTime
, 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...)
There a few issues/concerns that require attention. @sm453 , would appreicate your inputs, thanks.
1) Currently, there is a
SeaLevel
concept and aSeaLevelMeasurement
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 ofSeaLevel
each time we measure the global mean sea level or Singapore mean sea level, we have one instance ofSeaLevel
to represent the concept of the global mean sea level or Singapore mean sea level, then different instances ofSeaLevelMeasurement
to represent the sea level measured at different time. And thenom:Height
is linked toSeaLevelMeasurement
. @sm453, would appreciate your thoughts on whether this would be the good practice orom:Height
is to be linked toSeaLevel
andSeaLevelMeasurement
to be removed?2) Currently, the concept of
Damage
due to rising sea level is incorporated into OntoSeaLevel, and is linked directly toSeaLevelMeasurement
viahasImpact
. 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 haveSeaLevelRise
link to aSeaLevel
, and have a startingSeaLevelMeasurment
and an endingSeaLevelMeasurement
. Then, theDamage
concept can be linked to theSeaLevelRise
concept viahasImpact
and will no longer link toSeaLevel
.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.