Closed p-a-s-c-a-l closed 5 years ago
There is now a vocabulary called EU-GL. The description of every term of this vocabulary will be shown on the Information Page. There is only one term without parents called EU-GL as well. It contains the description of the EU-GL itself. Every other description has to be child or grandchild of this one term. Proposed Stucture
The structure has to follow the description of the EU-GL Modules as described in chapter 'CLARTIY Modelling Methodology' in deliverable D3.1 'Science Support Plan' (available on OwnCloud).
Here is a file containing a description of the hazards. When I produced this for the mock-up, I wasn't sure how much text would be required, so I kept it brief with the thinking that too much text may be too off-putting for the user. CLARITY Mockups_HazardDescription.docx
Thank you! I have updated the taxonomies with the information @RobAndGo provided.
The structure has to follow the description of the EU-GL Modules as described in chapter 'CLARTIY Modelling Methodology' in deliverable D3.1 'Science Support Plan' (available on OwnCloud).
I have created a new taxonomy following the structure of the D3.1 'Science Support Plan' under the name "EU-GL D3.1". Please take a look to verify everything is ok. Once verified we can delete the old one. Thank you!
We need also taxonomies for:
See the data-package specification
And probably more (to be discussed in Vienna)
I have created a new taxonomy following the structure of the D3.1 'Science Support Plan' under the name "EU-GL D3.1". Please take a look to verify everything is ok. Once verified we can delete the old one. Thank you!
Maybe it would have been better to update the old taxonomy as it is used in many other content entities.
@fgeyer16 @patrickkaleta Can you please check if this has any unwanted side-effects? E.g. gl_step/field_field_eu_gl_methodology (btw, why field_field ?!) refers to the old taxonomy. Same is be true for other content types. I think we have to update all existing content entities referring to the old taxonomy. Is this feasible?
Regarding the definitions of the emissions scenarios, once again this is information which I had sent to Refiz Duro in June when he was working on the mock-up.
Emissions scenario | Scenario Name
RCP2.6 | Early Response
RCP4.5 | Effective Measures
RCP8.5 | Business as Usual
For example, these would be the names that one would put on top of the hazard table when comparing the results across the emissions scenarios.
In addition, one would have to have a more detailed description of the emissions scenarios as a footnote to the page/report, or perhaps as a mouse-over pop-up on the page. The legend for the detailed description of the emissions scenarios would be something like:
Description of the Emissions Scenarios Early Response Scenario – RCP2.6: Radiative forcing peaks by mid-century to a value around 3.1 W/m^2, but returns to 2.6 W/m^2 by 2100 due to a significant reduction in greenhouse gas emissions over time. Effective Measures Scenario – RCP4.5: The application of a range of technologies and strategies for reducing greenhouse gas emissions is anticipated, which stabilize the total radiative forcing shortly after 2100 to 4.5 W/m^2. Business as Usual Scenario – RCP8.5: Greenhouse gas emissions increase over time owing to no intervention which lead to high greenhouse gas concentration levels by 2100 resulting in a radiative forcing of 8.5 W/m^2. Reference: Special Issue: The representative concentration pathways: an overview, Climatic Change, Volume 109, Issue 1-2, November 2011.
Indeed, and those are the names I have used also within the data-package specification :)
I think we also need the definition for the "baseline" scenario for the taxonomy,, the one with time period 1971-2000.
For the hazard index example we have setup we have baseline (1971-2000), rcp26 + rcp45 + rcp85 (2011-2040, 2041-2070, 2071-2100)
Regarding the definitions of the hazard indices, we do have an excel table which defines them all: Clarity_Hazards_Climate_Indices_2019_01_18.xlsx For each hazard index, its name, abbreviation, definition, and source is given.
@maesbri I/we have perhaps been a bit lazy with the use of the term baseline scenario. The "baseline" is actually not a "scenario". More correctly one would use "baseline climate" or "baseline period".
A suitable definition would be: Baseline climate/period: The 30-year period 1971-01-01 to 2000-12-31 used here to define a reference point for which the projected climate scenarios are compared against.
ok, then it is not part of the emissions scenario taxonomy.
I wonder if it would be convinient to define also a taxonomy for our time periods for the sake of completedness, although within the data package specification we are not using identifiers but real date numbers as it is a more general approach that allows to be reused for other purposes.
If you really wanted to define them, you could use something like: 2011-2040: Short-term (early 21st century) 2041-2070: Medium-term (mid-21st century) 2071-2100: Long-term (late 21st century)
Maybe it would have been better to update the old taxonomy as it is used in many other content entities.
@fgeyer16 @patrickkaleta Can you please check if this has any unwanted side-effects? E.g. gl_step/field_field_eu_gl_methodology (btw, why field_field ?!) refers to the old taxonomy. Same is be true for other content types. I think we have to update all existing content entities referring to the old taxonomy. Is this feasible?
@p-a-s-c-a-l
using a new taxonomy would mean a lot of additional work in this case, since the EU-GL taxonomy plays a central role in the CSIS and is not only used in content types but also in a couple of Views, which would have to be updated as well. I suggest to just copy the content of each term in Daniel's new taxonomy into the corresponding term of the current EU-GL taxonomy.
(btw, why field_field ?!)
Regarding the "fieldfield" question: when adding a new field to a content element, Drupal automatically prepends "field" as the machine name to the label the user enters. Seems like someone copied the machine name of an old field and used it as the label when creating this eu-gl-methodology field, eventuall leading to the name "field_field..."
@DanielRodera
Would it be sufficient to just copy the content of the Description-field of each term in your new taxonomy to the current EU-GL taxonomy terms, or is there something else in this new taxonomy (that's missing in the current one) which i just failed to notice?
After talking to Daniel, we decided to copy & paste the contents from the new taxonomy (EU-GL D3.1) into the original one (EU-GL) and delete the new taxonomy "EU-GL D3.1". I will take care of this.
I will take care about asking for a generic description of "Transport infrastructure" and "Urban infrastructure" for the "Study type" taxonomy.
We need also taxonomies for:
* hazards indexes
See the data-package specification
I have created/updated all the taxonomies for hazards, sub-hazards and indexes. The URL alias for each index matches with the ones defined in the data-package specification. I also added some images for the hazards provided by @RobAndGo.
As discussed last week during our meeting, I have updated the already existing "EU-GL" taxonomy with the content of Daniel's newly created "EU-GL D3.1" taxonomy and deleted the "EU-GL D3.1" taxonomy.
As discussed last week during our meeting, I have updated the already existing "EU-GL" taxonomy with the content of Daniel's newly created "EU-GL D3.1" taxonomy and deleted the "EU-GL D3.1" taxonomy.
@patrickkaleta thank you for the effort!
I was adding an extra field to some taxonomies (to map the taxonomies to the data-package specification) and I realized in the EU-GL taxonomy there are a lot of other terms such as ‘population’ or ‘buildings’ which shouldn’t be under the EU-GL. Following the structure described in the D3.1, the taxonomy should be like:
EU-GL
What we should do? Do we remove the other terms or move them into another taxonomy?
@DanielRodera I discussed this with Miguel yesterday and I removed the unneccessary items from this taxonomy. We also discussed the need for having the ability to display shorter titles in the study navigation (e.g. we cannot display "Implement/integration of adaptation action plan" since it's simply too long). I therefore suggested adding an additional field to this taxonomy that would store a shorter title, which can be displayed in the navigation. I already sent you and Miguel an email with more details.
@DanielRodera I discussed this with Miguel yesterday and I removed the unneccessary items from this taxonomy. We also discussed the need for having the ability to display shorter titles in the study navigation (e.g. we cannot display "Implement/integration of adaptation action plan" since it's simply too long). I therefore suggested adding an additional field to this taxonomy that would store a shorter title, which can be displayed in the navigation. I already sent you and Miguel an email with more details.
Hi @patrickkaleta,
I have changed the titles for each item according the latest Data Package specification. I also added the values for the “URL alias” and “id” fields.
Regarding the new field, I have created a new one called “tab title”, and input the main title until a shorter ones for the study navigation will be agreed.
@DanielRodera Could you please check revise the EU-GL Taxonomy, e.g. in Risk and impact assessment there are copy&paste artefacts from D3.x like "(see Section 3.3)". Furthermore, Hazard Characterization - Local Effects is not defined yet. Some info can be taken from the Local Effects section of the CLARITY DMP and there's also a PLINIVS abstract for ECCA2019 on OwnCloud. Thanks!
Another minor issue: URL alias /term/1 could be changed to some more readable and SEO friendly
Looks good, but if it's copy&pasted from somewhere outside of the project (e.g. not from a deliverable document), we have to use proper citations.
The actual descriptions of Elements at Risk (e.g. Buildings) are missing and the display shows IMHO Supported scenario instead of the ER description.
Definitions missing. I think this could be easily taken from the descriptions of the DCs.
This looks quite good. Some descriptions of 'top-level' hazards like Heat/Extreme Heat missing. Also others like Volcanic Eruption, but that's ok! (YAGNI). However, we should make sure that we have proper descriptions of HF & PF Hazards that play a role in the reference DC (DC1).
Descriptions missing. They could easily be obtained from WP3, e.g. D3.x or IPCC.
EU-GL Taxonomy
@DanielRodera Could you please check revise the EU-GL Taxonomy, e.g. in Risk and impact assessment there are copy&paste artefacts from D3.x like "(see Section 3.3)". Furthermore, Hazard Characterization - Local Effects is not defined yet. Some info can be taken from the Local Effects section of the CLARITY DMP and there's also a PLINIVS abstract for ECCA2019 on OwnCloud. Thanks!
Another minor issue: URL alias /term/1 could be changed to some more readable and SEO friendly
Hi Pascal, I have removed the "(see Section 3.3)" in the Risk and impact assessment description. Regarding the Hazard Characterization - Local Effects is not defined in the D3.1 as a EU-GL step (following the deliverable, should be removed), this is the reason why is not defined. I guess you are using the Hazard Characterization - Local Effects step for another things in the CSIS. If is ok for you to keep as a step in the methodology, I will add their description!
Sector Taxonomy
Looks good, but if it's copy&pasted from somewhere outside of the project (e.g. not from a deliverable document), we have to use proper citations.
You are right, citations added!
HC-LE is described in D3.2, chapter 2.2. But you're right, not as distinct step of the EU-GL methodology. It's also part of the Mock-Up and needed as distinct step in CSIS to show the difference in quality/detail between HC and HC-LE. So yes, it's needed. :-)
HC-LE is described in D3.2, chapter 2.2. But you're right, not as distinct step of the EU-GL methodology. It's also part of the Mock-Up and needed as distinct step in CSIS to show the difference in quality/detail between HC and HC-LE. So yes, it's needed. :-)
ok, description added.
Emission Scenario
Descriptions missing. They could easily be obtained from WP3, e.g. D3.x or IPCC.
Done
Exposure Taxonomy
The actual descriptions of Elements at Risk (e.g. Buildings) are missing and the display shows IMHO Supported scenario instead of the ER description.
So far taxonomy terms were displayed directly inside the studies, so the taxonomy term pages themselves (/taxonomy/term/[TermID]) have not been configured yet and show default behaviour - meaning that on top the description field is displayed and underneath related content referencing this term.
E.g. in the case of the Brigdes term only one Supported scenario is displayed, since the term has no description and it is being referenced by one Supported scenario.
O.K. I think for DC1 (Reference DC) we need ER Taxonomies for Buildings, Roads and Population.
Study Type
Definitions missing. I think this could be easily taken from the descriptions of the DCs.
We agreed in Vienna to ask PLINIVS for this definition, I sent a mail about month ago and I havent got any response. I just send a reminder and I also have asked for another definitions we still missing.
I have addded the "elements att risk" and "study type" taxonomies with the information Mattia provided.
We renamed "Exposure" taxonomy by "ElementsAtRisk" as it also contains the vulnerability classes for each category (and in a next step we will add the corresponding damage classes as well)
White Paper on taxonomies for the environmental use of proceeds https://www.eib.org/en/investor_relations/cab/taxonomy-white-paper/index.htm
https://www.adb.org/documents/project-classification-system-final-report Asian bank, Project Classification System: Final Report
There are still a lot of taxonomy terms missing. E.g. for Heat: (heat / extreme heat)
We are missing a useful Impact Scenarios Taxonomy that is needed for the RA/IA Data Package.
@humerh @stefanon any idea, what to put i n there?
I think the data involving the taxonomy terms for heat and the other indices was to be summarised in the attached table. Naming_of_layers_LE_zamg.xlsx
I have completed the table for all indices which were planned to the best of my knowledge.
I think the data involving the taxonomy terms for heat and the other indices was to be summarised in the attached table. Naming_of_layers_LE_zamg.xlsx
It is incomplete (my fault!), and I'll fill it out now and update the above link as I go.
Thanks @RobAndGo, I will update the taxonomies once you update the excel.
There are still a lot of taxonomy terms missing. E.g. for Heat: (heat / extreme heat)
I added again the "heat" definition.
@DanielRodera could you please have a look at the EU-GL taxonomies and correct the errors in the references? See https://github.com/clarity-h2020/csis/issues/104
Create the Vocabularies for "Information Pages" for describing the EU-GL Methodology, the Information on hazards, etc.
WP3: Create the respective content, e.g. description of EU-GL Modules, Hazards, etc.**
This information will also be included in the report. E.g. create one taxonomy term for each EU-GL Module and a vocabulary for EU-GL, Same for Hazard, Exposure, etc. The vocabulary itself can have additional fields, e.g. 'description'.
@fgeyer16 Check if we can add more fields to a vocabulary.
SCC dissemination team: "polish" content and add pictures