API function for accessing parameter classes and parameter about spine-database-api HOT 11 CLOSED

In GitLab by @steffenkaminski on Jan 18, 2019, 17:51

changed the description

from spine-database-api.

In GitLab by @steffenkaminski on Jan 18, 2019, 17:52

changed the description

from spine-database-api.

In GitLab by @manuelma on Jan 18, 2019, 21:52

I'm not sure what you mean by parameter class. Can you please take a look at this wiki and see if it helps you clarify?

Chances are that the Spine database API already provides those functions you're describing, or very similar ones.

from spine-database-api.

In GitLab by @manuelma on Jan 19, 2019, 15:15

I guess when you say parameter class you actually refer to the parameter table, where the definition of a parameter is hold. And when you say parameter you actually refer to the parameter_value table, which holds the value for a certain combination of parameter and object/relationship.

I believe that confusion is partly our fault. We are discussing about renaming the current parameter table to parameter_definition, hopefully to avoid that confusion. Do you think it could help?

Back to the original question, if my guess above is correct, then I believe we have more or less the methods you need:

def parameter_list(self, id_list=None, object_class_id=None, relationship_class_id=None):
   """Return all entries from the `parameter` table, either filtered by a list of parameter ids, 
   an object class id, or a relationship class id.
   """

def parameter_value_list(self, id_list=None, object_id=None, relationship_id=None):
   """Return all entries from the `parameter_value` table, either filtered by 
   a list of parameter value ids, an object id, or a relationship id.
   """

Maybe we should add an additional optional argument to parameter_value_list, called parameter_id?

from spine-database-api.

In GitLab by @steffenkaminski on Jan 29, 2019, 12:36

Thank for the very quick reply and sorry for the late response. Indeed I meant what you guessed: With parameter value I meant parameter.

In fact this were the two methods I was looking for. By some reasons I haven't found them. Thank you very much for clarification. Adding a parameter_id keyword argument would also be nice feature to have.

from spine-database-api.

In GitLab by @steffenkaminski on Jan 29, 2019, 12:38

closed

from spine-database-api.

In GitLab by @steffenkaminski on Jan 30, 2019, 10:16

reopened

from spine-database-api.

In GitLab by @steffenkaminski on Jan 30, 2019, 10:27

Another thought:
It would also be really helpful to have this functionality accessible in Julia through a convenience function. I know that this would brake a little with the structure, but it would also give some more freedom.

something like:
Parameters(object_class=”unit”) or Parameters(relationship_class=”unit__commodity”)
Returning a list of symbols containing the name of the parameter

What do you think?

I believe that confusion is partly our fault. We are discussing about renaming the current parameter table to parameter_definition, hopefully to avoid that confusion. Do you think it could help?

For me it would be most logically to name "parameter" class to "parameter class". This would align with "object class" and "relationship class" classes. Following "parameter_value" would become "parameter". But I don't have a strong opinion on that. Having a look at the UML diagram gives the user some clarification.

from spine-database-api.

In GitLab by @jkiviluo on Jan 31, 2019, 10:32

@steffenkaminski It's an interesting thought to rename parameter_definition as parameter_class. It probably makes sense from the Spine Model perspective, but on the database side it might be a misnomer, since parameters are not 'objects' or 'entities' there. In the EAV model they are the 'A' - attributes with a Value.

from spine-database-api.

In GitLab by @steffenkaminski on Jan 31, 2019, 12:36

I'm quite far from being a data scientist! Looking at the database using a viewer parameters and parameter_values all seem to be table names. So in my mind all those tables seem to be classes (as in Manuels UML diagram). In this tables the single "objects" seemed to be stored in rows. Those "object" seem to be connected via their ids-"attributes"(?).

But never mind, it is also clear enough with the current names!

from spine-database-api.

In GitLab by @manuelma on Mar 25, 2019, 17:41

closed

from spine-database-api.