Auto-generated table
I've updated the code to automatically grab some of the facts about the models that are stored on the pages. I don't know if what I've put up there is the most useful collection of items, but if you look at the bottom of each of the model pages, you'll see a box with "Facts about...". On the left side of this are the names of the properties which you can use with the inline query syntax (https://semantic-mediawiki.org/wiki/Help:Inline_queries) on this page.
- This is great! I would guess that the maintaining institution (shown as "by XYZ" on the model page) would be a great field to show. However, I could not figure out the correct syntax for that query.
- <del>This is great! I would guess that the maintaining institution (shown as "by XYZ" on the model page) would be a great field to show. However, I could not figure out the correct syntax for that query.</del>
Edit: thank you for adding the author institution field to the table.
- The fact box on the individual model pages should help you see the names of the properties that you can query. You can also test out queries on http://wiki.openmod-initiative.org/wiki/Special:Ask
- For some reason (probably my browser caching, or just me not scrolling, ...) I did not see the generated attribute table below the "old" factsheet, so I thought I had to "guess" the correct attribute name spelling.
- It wasn't there when you looked for it :-) I had removed it again but now it's back there.
Field "Is suited for many scenarios" in Section "Overview of models by purpose, scope and modelling type"
I am just wondering what is meant by this field.
Suited in terms of runtime?
Best
Cord
- I read that as suited in terms of data preparation, meaning that new scenarios could be created from a reference scenaro by difference. This needs to be cleared up.
Suggestions
After offline discussions with Ingmar, I am going to edit the logic behind the Planned to open up in the future flag so that this flag is greyed out when Open Source licensed is set to true. Otherwise the flag is rather meaningless when a permissive license like the MIT license has already been checked.
Some further questions and suggestions for improvement:
should add: Modeled commodities (Other): Supercritical CO2 (for CCS technologies)
under Transfer (Heat): does heat transmission (that is, long-distance heat transport) make any sense?
the Network coverage fields AC load flow and DC load flow are ambiguous: the basic AC load flow model is very often (and confusingly) termed DC load flow (see end of message for details) — so the associated help message should make the distinction crystal clear
the various Property:* pages should explain the meaning of their field at the very top of the page
the Property:Math modeltype should also accept the following values: accounting, hybrid, and game theory. And possibly energy-economy or economic equilibrium or general equilibrium (for top-down models, of which there are none so far), and also input/output, econometric, and integrated assessment (for completeness, more than anything else, at this point)
the Property:License need only record the abbreviated form of the license where it is well known, for example: GPLv2 and not GNU General Public License version 2.0. The Property:License page can then contain a list of expansions
the Property:Model source public could be renamed Property:Distribution and contain the values: git repository, svn repository (though subversion is not common), anonymous download, registration, and by invitation (meaning that new project members will be screened and approved)
a new Property:First release date to record the year or full date of first public release (this would also provide interesting historical information)
a new Property:Final release date to record the abandonment of a project
a new Property:Status which accepts: planned, active, unmaintained, and discontinued (this would allow users to see which projects are alive and which have been abandoned)
In addition:
perhaps the license information should be split into Property:Code license and Property:Data license to distinguish between the codebase (say GPLv3) and datasets (often CC BY 4.0)
The AC/DC load flow naming issue:
Andersson (2008) on page 59 explains that the active power flow equation for fixed-frequency AC power is analogous to Ohms law applied to a resistor carrying DC current. Hence this form of AC power analysis is regularly referred to as DC load flow analysis.
References
Andersson, Göran (2008). Modelling and analysis of electric power systems: power flow analysis fault analysis power systems dynamics and stability (PDF). Zürich, Switzerland: ETH. Retrieved 2016-12-08.
