Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

start time and ending time don't work as they should #572

Closed
5 tasks
sfluegel05 opened this issue Oct 19, 2020 · 14 comments
Closed
5 tasks

start time and ending time don't work as they should #572

sfluegel05 opened this issue Oct 19, 2020 · 14 comments
Assignees
Labels
[B] restructure Restructuring existing parts of the ontology oeo dev meeting Discuss issue at oeo dev meeting oeo-shared changes the oeo-shared module

Comments

@sfluegel05
Copy link
Contributor

Description of the issue

This comes from #267 and the discussion of the issue in dev-meeting 10.

If we have different time steps which share a common "border time", say 11:00-12:00 and 12:00-13:00, 12:00 is a zero-dimensional temporal region that is a start time (because of its "role" for the first time step) as well as an ending time (because of the second time step).

This leads to the problem that a time step can have two zero-dimensional temporal regions associated with it via a has part relation. Both zero-dimensional temporal regions can be start and ending times because of their use in this and / or other time steps. In that situation it gets hard to determine which of the zero-dimensional temporal regions is the start and which the ending time.

Ideas of solution

This can be prevented by using different object properties like has start time and has ending time instead of has part, which refer directly to a zero-dimensional region instead of start time and ending time. This way, start / ending time would get replaced by object properties.

Workflow checklist

  • I discussed the issue with someone else than me before working on a solution
  • I already read the latest version of the workflow for this repository
  • The goal of this ontology is clear to me

I am aware that

  • every entry in the ontology should have a definition
  • classes should arise from concepts rather than from words
@sfluegel05 sfluegel05 added [B] restructure Restructuring existing parts of the ontology To do Issues that haven't got discussed yet oeo-shared changes the oeo-shared module labels Oct 19, 2020
0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q added a commit that referenced this issue Oct 21, 2020
- remove start time, ending time subclasses of zero-dimensional temporal
  region
- add has start time, has ending time relations as subclasses of
  has part
- adjust time step to include new relations
@sfluegel05
Copy link
Contributor Author

To make it consistent, we should also transform time stamp from a class to an object property. Our object properties need definitions as well. My suggestions:

  • has start time: A relation between a one-dimensional temporal region and a zero-dimensional temporal region where the zero-dimensional region indicates the beginning of the one-dimensional region.
  • has ending time : A relation between a one-dimensional temporal region and a zero-dimensional temporal region where the zero-dimensional region indicates the end of the one-dimensional region.
  • has time stamp: A relation between a time step and a zero-dimensional temporal region where the zero-dimensional temporal region is used to describe the time step.

What do the other experts think about this topic? @OpenEnergyPlatform/oeo-general-expert-formal-ontology

@akleinau
Copy link
Contributor

the definitions are complex to read, but good (maybe use abbreviations for simplicity? 1d-region or something like that? but thats not necessary).

I think Timestamp can be both. I don't see a logical problem like the one described above for start and end time. So question is would it be helpful for the users of our ontology if timestamp is a class?

@akleinau
Copy link
Contributor

akleinau commented Oct 23, 2020

the pull request #573 stated the domain of start time as 'has start time' exactly 1 'zero-dimensional temporal region' and the domain of ending time the same way.

I think the underlying idea of that is that a process can always have just one start time.
The implementation here is not correct, it states that just a class with exactly one "has start time" relation can get the relation "has start time", which is paradox.
My proposed implementation of that would be to make the properties "start time" and "end time" functional. Which means for each element of the domain (here processes) there is exactly one element of the range (here 0-dim regions, the start times)

@github-actions github-actions bot removed the To do Issues that haven't got discussed yet label Oct 23, 2020
@MGlauer
Copy link
Contributor

MGlauer commented Oct 23, 2020

Could we reuse the has_beginning, has_end relations from the owl-time ontology?

@sfluegel05
Copy link
Contributor Author

hasBeginning and hasEnd from the owl-time ontology are defined as Beginning / End of a temporal entity. (temporal entity is quite similar to our temporal region). So this would basically be a shorter (and probably more understandable) version of my definition.

@stap-m
Copy link
Contributor

stap-m commented Oct 28, 2020

I didn't take part in the last meeting, so it is hard for me to reconstruct the discussion and I don't really get the problem.

A general question: How is a 0-dim temporal region related to its value (e.g. 12:00)? Is the value directly a data property of the 0-dim temporal region or is it related to a quantity value?

And time stamp should be a quantity value in my opinion, or if an entity in reality is needed, an information content entity. It contains of a value (e.g. 12:00), sometimes a time standard (e.g. UTC). The relation has time stamp doesn't make sense to me. How would it be used?

@sfluegel05
Copy link
Contributor Author

The idea (as far as I understand it) is that we have a zero-dim temporal region which is related to quantity values via has quantity value. These quantity values consist of a unit (like minute, hour, year, ...) and a number (e.g. 12).

For time stamp I wanted to treat it similar to start / ending time because in two of three cases it is the same as a start / ending time. has time stamp some zero-dim temporal region would be used as a substitute for the has part some time stamp-relation we currently have for time step.

@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Contributor

The idea (as far as I understand it) is that we have a zero-dim temporal region which is related to quantity values via has quantity value. These quantity values consist of a unit (like minute, hour, year, ...) and a number (e.g. 12).

You also need a reference point. A quantity value (-5) and unit (seconds) only gives you five seconds before something, not an absolute position (T - 5 seconds, where T is the reference point).
#567 (comment)

The reference point may be implied, as in ISO 8601, but it has to be there. owl-time seems to have more thought put into it than BFO …

@stap-m
Copy link
Contributor

stap-m commented Oct 29, 2020

The idea (as far as I understand it) is that we have a zero-dim temporal region which is related to quantity values via has quantity value. These quantity values consist of a unit (like minute, hour, year, ...) and a number (e.g. 12).

Ok, I agree. We'd need a concept as subclass of quantity value here. In my opinion, the respecive class is time stamp. Time stamp is not a 0-dim temporal region itself.

@stap-m
Copy link
Contributor

stap-m commented Oct 29, 2020

A: time step has start time 0-dim temporal region has quantity value 01.01.2020 12:00:00 UTC
B: time step has part start time has quantity value 01.01.2020 12:00:00 UTC
Since the values are assigned via the quanity value, why does B cause problems and A doesn't?

@sfluegel05
Copy link
Contributor Author

B causes problems if you also have
C: time step has part end time has quantity value 01.01.2020 12:00:00 UTC
for another time step.
Then you have two options: The start time from B and the end time from C are different individuals. That would be bad because it lead to two different individuals which describe the exact same thing. The other option is using the same individual for B and C. This individual would then be classified as a start time and as an ending time. So when we look at our time step from B again, we have a has part-relationship with a start and ending time and don't know anymore if it is the start or the end of the time step. (Of course you could still find out which one it is if you want to, but it gets harder and more confusing, the more start and ending times you add)

Ok, I agree. We'd need a concept as subclass of quantity value here. In my opinion, the respecive class is time stamp. Time stamp is not a 0-dim temporal region itself.

That's an interesting idea. So time stamp would be some sort of "absolute time value"-class. I'm not sure if quantity value fits as a parent class for this, since 01.01.2000 12:00:00 is not really a numeral and UTC not really a unit. As @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q pointed out, the owl-time-ontology has some useful concepts which could help us with the representation of time values.

@sfluegel05 sfluegel05 changed the title start time and end time don't work as they should start time and ending time don't work as they should Oct 29, 2020
@0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q
Copy link
Contributor

B causes problems if you also have
C: time step has part end time has quantity value 01.01.2020 12:00:00 UTC
for another time step.
Then you have two options: The start time from B and the end time from C are different individuals. That would be bad because it lead to two different individuals which describe the exact same thing.

Are you positive on this? Are there individuals in the ontology to begin with?
If I want to annotate my data set with OEO, I surely don't need to edit the ontology to create some representation for all the time steps/stamps I need, no? I expect to have to generate meta data that looks something like

  "time step": [
    {
      "id": "2005",
      "start time":  "2003-01-01 00:00:00 UTC",
      "ending time": "2008-01-01 00:00:00 UTC"
    },
    {
      "id": "2010",
      "start time":  "2008-01-01 00:00:00 UTC",
      "ending time": "2013-01-01 00:00:00 UTC"
    },
    ...
  ],

(but I'm not sure, and my questions concerning this so far weren't answered conclusively).
So in what sense are there individuals in the ontology?

So when we look at our time step from B again, we have a has part-relationship with a start and ending time and don't know anymore if it is the start or the end of the time step.

I don't get that either.
There are two time steps, let's call them "B" and "C". Both link (have a relation) to the temporal instant "01.01.2020 12:00:00 UTC", let's call it T. B's relation is has part start time, so T is the start of B. C's relation is has part ending time, so T is the end of C.

I'm puzzled.

@sfluegel05
Copy link
Contributor Author

There are two time steps, let's call them "B" and "C". Both link (have a relation) to the temporal instant "01.01.2020 12:00:00 UTC", let's call it T. B's relation is has part start time, so T is the start of B. C's relation is has part ending time, so T is the end of C.

B's relation is has part T and C's relation is has part T in this case. T has the relations Type: start time and Type: ending time. This is all assuming we use individuals for temporal instants in the ontology.

So in what sense are there individuals in the ontology?

That is a good question and I am not sure about this. Maybe @MGlauer, who originally brought up this issue, or someone else from @OpenEnergyPlatform/oeo-general-expert-formal-ontology knows more.

@stap-m stap-m added the oeo dev meeting Discuss issue at oeo dev meeting label Nov 9, 2020
@sfluegel05
Copy link
Contributor Author

In dev-meeting 11, we decided to close this issue, since we were not sure if there are use cases for which this problem arises.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[B] restructure Restructuring existing parts of the ontology oeo dev meeting Discuss issue at oeo dev meeting oeo-shared changes the oeo-shared module
Projects
None yet
Development

No branches or pull requests

6 participants