Special weather time series types

[ap-peh]

Description of the issue

How is it possible to annotate special weather time series types. In a forecast model I have different input time series. Among others a time series of snow cover in mm and direct solar radiation in kW. For both I have chosen the entity "weather time series". For the direct solar radiation time series I have created a relationship via the property "is about" to an individual of the entity "direct solar radiation". For the snow cover time series this was not possible, because there is no entity that expresses that it is about snow cover. The question now is, if it is at all intended to connect a weather time series via the property "is about" to an entity with meta knowledge about the time series like "direct solar radiation" or if more specific SubClasses of weather time series should be defined.

Ideas of solution

If a weather time series is best defined using the "is about" property, or possibly another property, I would suggest adding the "snow" subclass below the "water" entity. However, if a weather time series should be better described with a subclass of the entity "process", as it would be the case for "direct solar radiation" or e.g. for a wind speed time series, I would suggest to create an entity "snow cover" or "snowfall rate" below the process.

However, if it would be better to create more specific weather time series, I would suggest to create e.g. an entity "snow cover time series", "wind speed time series", "direct solar radiation time series" etc.

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

[stap-m]

ENVO has a concept for snow which could be reused. It is classified as environmental material, a class that OEO does not have. But water might be a good parent class for us.
For both, water and snow, a quality depth or level could be introduced.

[l-emele]

As we do not have an environmental material, I would not reuse ENVO's definition, try to find our own.

I suggest:

• Snow is water in form of flakes of crystalline water ice.
• Axiom: snow 'has state of matter' value solid

[stap-m]

I'm ok with your proposal. Since it seems to be at least inspired by ENVO, we might cite or mention it, though, e.g. by an annotation may be identical to or definition source.

[stap-m]

I'd be ok to introduce specific weather time series, as proposed by @ap-peh , maybe as equivalent classes.

Regarding the axioms for specific weather time series, is about is probably the best that we have at the moment. But I think creating a subproperty that is more specific, in the sense that the time series represents the very parameter referred to, is a good idea for proper time series description.

[ap-peh]

Another time series needed for a forecasting model is a consumption time series. Here, too, the entity Consumption already exists and should be used to express that the time series to be described is a consumption time series or should an extra entity be introduced as in the case of the weather time series.

[stap-m]

Another time series needed for a forecasting model is a consumption time series. Here, too, the entity Consumption already exists and should be used to express that the time series to be described is a consumption time series or should an extra entity be introduced as in the case of the weather time series.

consumption time series EquivalentTo: 'time series' and 'is about' some consumption
just like this @ap-peh?

[stap-m]

From your comment, I figure that forecast time series should be an own type of time series, since weather time series can be forecast time series or measured or even modelled/synthetic time series.

This might require a complex parallel structure of equivalence dependencies. But probably useful.

[ap-peh]

Another time series needed for a forecasting model is a consumption time series. Here, too, the entity Consumption already exists and should be used to express that the time series to be described is a consumption time series or should an extra entity be introduced as in the case of the weather time series.

consumption time series EquivalentTo: 'time series' and 'is about' some consumption just like this @ap-peh?

I would suggest creating a specific property for the statement: The time series is of type XY. This makes it clear that if this property is used, then it is a relationship between a time series and the type assigned to it. To keep the entity time series consistent I would remove special entities like generation time series.

[stap-m]

I would suggest creating a specific property for the statement: The time series is of type XY.

Ok, good idea. time series, being GDCs, are not intuitive for adding properties, i.e. SDCs, yet we did it already for some entities, e.g. model. There we chose role, which might be the most suitable SDC here, too. @viktorwichern @nelekoehler can you backcheck with BFO please?

I see several roles then: forecast, measured, synthetic, weather, generation, consumption
Are there more?

[l-emele]

Can we please start with definitions first before deciding how we implement this? I have not seen any proposals for definitions yet.

For forecast time series I see two completely different possible definitions:

• A forecast time series is a time series that is used to compute a forecast.
• A forecast time series is a time series containing forecast.

These are two completely different things: the first one is an input into some forecasting process, the other the result of a forecasting process.

[l-emele]

Proposal for a time series specific subproperty of is about:

• is time series of: A relation that relates a time series to an entity that it contains data of.

Then e.g. the axiom
'generation time series' 'is about' some ('electricity generation process' and ('has participant' some 'power plant'))
can be refined to
'generation time series' 'is time series of' some ('electricity generation process' and ('has participant' some 'power plant'))

[stap-m]

For forecast time series I see two completely different possible definitions:

• A forecast time series is a time series that is used to compute a forecast.
• A forecast time series is a time series containing forecast.

I have the second "type" in mind, i.e. output of a forecast computation.
To draft a definition and come back to my proposal above: forecast time series role (or other kind of SDC): A forecast time series role is a role of a time series that is output of a forecasting model calculation.

forecasting model calculation is obviously not (yet) part of the OEO, though.

[viktorwichern]

Ok, good idea. time series, being GDCs, are not intuitive for adding properties, i.e. SDCs, yet we did it already for some entities, e.g. model. There we chose role, which might be the most suitable SDC here, too. @viktorwichern @nelekoehler can you backcheck with BFO please?

So, the definition for role in the BFO is:
Each instance of role is a realizable entity that (1) exists because the bearer is in some special physical, social, or institutional set of circumstances in which the bearer does not have to be (optionality), and (2) is not such that, if this realizable entity ceases to exist, then the physical make-up of the bearer is thereby changed (external grounding).

For GDC's, their "aboutness" defines their physical properties. So if the relation (through a SDC) we want to express would concern their "aboutness" this would be inconsistent with the definition of role. If a PDF could have the role to be "about", say, weather, instead of budgeting plans, if it would lose this role, it would cease to be what it was. Therefore, roles cannot dictate the "aboutness", especially of information content entities. A possible role could be something like "study material". A PDF could either be (used as) study material or not, if it would lose the role, the PDF would not change.

Also, role is a realizable entity, which is defined as having at least one independent continuant entity as its bearer, so a GDC probably can't have a role anyway.

.. which is kind of unfortunate, because function feels like it would fit pretty well here (but it is a realizable entity)

A function is a special kind of disposition. It is a realizable entity whose realization is an end-directed activity of its bearer that occurs because this bearer is (a) of a specific kind and (b) in the kind or kinds of contexts that it is made or selected for. Thus a function is a disposition that exists in virtue of the bearer’s physical make-up, and this physical make-up is something the bearer possesses because of how it came into being—either through natural selection (in the case of biological entities) or through intentional design (in the case of artifacts). Roughly, the entities in question came into being in order to perform activities of a certain sort, called “functionings.”

TL;DR: I do not think SDC's can inhere in GDC's, but this is very complicated and I would like a second opinion, preferably from another philosopher. Also, roles should theoretically not concern the aboutness (of information content entities).

[stap-m]

Also, role is a realizable entity, which is defined as having at least one independent continuant entity as its bearer, so a GDC probably can't have a role anyway.
[...]
TL;DR: I do not think SDC's can inhere in GDC's, but this is very complicated and I would like a second opinion, preferably from another philosopher. Also, roles should theoretically not concern the aboutness (of information content entities).

In general, you are right. SDC are supposed to only have IC as bearer. Yet, in "real ontology development", it showed that some GDC also require specific "properties". I discussed this with @fneuhaus several times, and it seems that in other ontology communities this constraint is weakend as well.
In the OEO, we added the model role to model (GDC), for instance.
If you're interested in this discussion, we can ask @fabianneuhaus to discuss this in a meeting.

EDIT: see also: #1444 (comment)