Choosing constraints: parameter vs. relationship about spine-database-api HOT 13 CLOSED

In GitLab by @jkiviluo on Sep 14, 2018, 11:33

That description was supposed to be free of opinion (probably quite not so) and Kris helped me to modify it to that direction (while also giving other input). So, I just wanted express my main reason why relationships would be great:

Using relationships needs additional objects (Data Store gets bit more complex), but I believe that life is easier in the end. I think it's important to have a clear separation between data and function. With this you can make re-usable databases that try to contain all possible data. Then you just apply rules how you want to use the database in a particular task (e.g. you might want to use the same data in different ways for the investment model and the UCED model that you run iteratively). I think it's more straightforward to keep the parameter data same and just create separate model instances where you select bit different methods for some of the features.

Now, that's just my current view. Good arguments in either direction are very welcome.

from spine-database-api.

In GitLab by @manuelma on Sep 16, 2018, 12:02

Nice post @juha_k. I just have a couple of questions:

unit_A.max_upward_primary_reserve = 0

From this I understand that if we want to 'deactivate' a parameter, we set its value to zero. Does that work? What if zero is a meaningful value?

• What happens when there is both time series and constant values for e.g. upward_primary_reserve? How to decide which one is used?

This is an interesting question, but I don't see how it relates to the main issue? --At the moment, JuMP_all_out prioritizes the time series (json column) over the constant (value column).

relationships between methods and parameters

establish relationships between the method objects and the parameters

Just to be sure, do you mean define parameters for method objects? Because we can't define relationships between objects and parameters.

from spine-database-api.

In GitLab by @DillonJ on Sep 17, 2018, 12:15

My main problem with this approach is that relationships indicate some sort of relationship between objects

Parameters are data that tell us things about objects.

However, this relationship: node_Leuven__require_upward_primary_reserve is not a relationship between objects in any meaningful definition of an object. It's really a parameter masquerading as a relationship...

This also means that require_upward_primary_reserve is an object class.

So we have to create this new object class (that will appear in the tree) what are the object instances then and what do they represent? I suspect you're going to need something in "quotes".... my worst nightmare :)

As @manuelma alludes to, I think there are hidden implementation issues here. It just seems too awkward and non-intuitive.

I don't think using relationships in this way achieves separation of data and function... relationships are just as much data as parameters.

In the end of the day, you create parameters to indicate function, or create relationships (meaning you also need to create mostly empty new object classes and object instances)...

I really think it's not using objects and relationships in a nice way. It feels like a twisting of the data structure...

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 12:15

From this I understand that if we want to 'deactivate' a parameter, we set its value to zero. Does that work? What if zero is a meaningful value?

I don't know how it would work with the value field. For JSON we could use things like NaN. That might mean that we would not have a separate value field, just the JSON. But maybe there is another way to solve this.

This is an interesting question, but I don't see how it relates to the main issue? --At the moment, JuMP_all_out prioritizes the time series (json column) over the constant (value column).

It's a difference between the parameter and relationships approaches. With the relationship approach it is straightforward to establish which one is used (you select 'times series' method or a 'constant' method). With the parametric approach there needs to be a convention (that the user must know) or some other way to establish precedence.

Just to be sure, do you mean define parameters for method objects? Because we can't define relationships between objects and parameters.

Good point. We would need to either have object_class parameters that would list all the parameters (automatically) so that we can create that relationship or then allow a relationship between an object and parameter. We don't need to do this right away - it's only later when we want to enable parameter validation with archetypes.

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 12:17

@DillonJ require_upward_primary_reserve would not be an object class. It would be an object of the method class. Please re-consider with this in mind.

from spine-database-api.

In GitLab by @DillonJ on Sep 17, 2018, 12:22

@juha_k We already have a working mechanism for dealing with time varying data I.e. you can specify a constant value, a time patterned value, link to a time_series object or embed a time series in the json and as @manuelma mentions, JumpAllOut already supports this.

This is a huge case for a parameter based approach because we have no mechanism for time varying relationships, which in my view, would be very messy.

An advantage of the parameter based approach is also that they can be defined, if we wish, on the relationship between the entity and a temporal_stage object and take different values for each temporal stage, thus giving us significant capability in terms of having different formulations in different temporal_stages.

from spine-database-api.

In GitLab by @DillonJ on Sep 17, 2018, 12:34

Another issue is that you would need to refer to require_upward_primary_reserve in "quotes" and if it's wrong, you won't get an error. If you used parameters with enumeration as proposed in require_upward_primary_reserve you could write something like:

   if(require_upward_primary_reserve(unit=u) == upward_primary_reserve_required  
     #do stuff

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 12:50

This is a huge case for a parameter based approach because we have no mechanism for time varying relationships, which in my view, would be very messy.

Number data would always be in parameters, including time varying data. There is no need for time-varying relationships (I don't even know what you mean by it). The relationships are only used to say when the number data is used and when it is not used. (And if there is a need to say that something starts from T=5, then a number must be given in a parameter field).

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 12:52

An advantage of the parameter based approach is also that they can be defined, if we wish, on the relationship between the entity and a temporal_stage object and take different values for each temporal stage, thus giving us significant capability in terms of having different formulations in different temporal_stages.

We can also have unit__method__temporal_stage relationship when needed. The same capability is there too.

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 12:56

Another issue is that you would need to refer to require_upward_primary_reserve in "quotes" and if it's wrong, you won't get an error.

I don't get this. In Spine Model, one would have sets. No quotes needed. If you write something wrong in Spine Model, like unt instead of unit you are supposed to get an error so that you know to correct your mistake. Isn't that a good thing?

from spine-database-api.

In GitLab by @DillonJ on Sep 17, 2018, 12:58

I don't get this. In Spine Model, one would have sets. No quotes needed. If you write something wrong in Spine Model, like unt instead of unit you are supposed to get an error so that you know to correct your mistake. Isn't that a good thing?

Yes, it's a good thing, that was my point. With "stuffinquotes" you don't have this safeguard.

from spine-database-api.

In GitLab by @jkiviluo on Sep 17, 2018, 13:37

So, just to make clear. require_upward_reserve would be without quotes in Spine Model (it's an object) and would thus have error checking. I suppose it's still open how to get subsets in Spine Model, but's that's separate thing. Discussed in https://gitlab.vtt.fi/spine/data/issues/8.

from spine-database-api.

We're nowadays using parameters that are methods and in 0.8.2 we will get method parameter type (with some additional functionality).

from spine-database-api.