Gap analysis: Difference between revisions

From EERAdata Wiki
Jump to navigation Jump to search
Access restrictions were established for this page. If you see this message, you have no access to this page.
Christopherbs (talk | contribs)
Christopherbs (talk | contribs)
Added Simple Dublin Core element table
Line 23: Line 23:


{| class="wikitable"
{| class="wikitable"
|+ style="caption-side:bottom; color:#000000;"|''This table shows a summary of the specific issues that were identified in Workshop 1. The aim was to categorise different issues to get a better understanding of how to tackle these challenges.''
|+ This table shows a summary of the specific issues that were identified in Workshop 1. The aim was to categorise different issues to get a better understanding of how to tackle these challenges.
|-
|-
! General Issue!! Specific Issues!! Results !! Solutions
! General Issue!! Specific Issues!! Results !! Solutions
|-
|-
| Privacy issues and expected disadvantages
! Privacy issues and expected disadvantages
||  
||  
* Not publishing data due to privacy concerns (sensitive data)  
* Not publishing data due to privacy concerns (sensitive data)  
* UC2: In case of distribution network data this is relevant
* Data publishing could lead to potential market disadvantages/competition
* Data publishing could lead to potential market disadvantages/competition
* UC2: In case of distribution network data this is relevant
* …
* …
|| No data published at all
|| No data published at all
Line 37: Line 38:


|-
|-
| Licensing
! Licensing
||  
||  
* No licenses available may mean the data is not reusable for the researcher
* No licenses available may mean the data is not reusable for the researcher
Line 46: Line 47:


|-
|-
| Taxonomy/ontology/common vocabulary and language issues
! Taxonomy/ontology/common vocabulary and language issues
||  
||  
* Lack of standardisation
* Lack of standardisation
Line 57: Line 58:


|-
|-
| Metadata range||
! Metadata range
||
* Different field require different metadata (potentially very specific)
* Different field require different metadata (potentially very specific)
* UC3: additional metadata for applications of materials
* UC3: additional metadata for applications of materials
Line 64: Line 66:


|-
|-
| Linking issues
! Linking issues
||
||
* Missing identifiers on websites
* Missing identifiers on websites
Line 77: Line 79:


|-
|-
| Quality of data
! Quality of data
||
||
* No qualitative assessment of the data itself (which may be limited)
* No qualitative assessment of the data itself (which may be limited)
Line 88: Line 90:


|-
|-
| Conducting FAIR assessments
! Conducting FAIR assessments
||  
||  
* Discrepancies between results conducted by humans versus machines
* Discrepancies between results conducted by humans versus machines
Line 103: Line 105:
|+Food complements
|+Food complements
|}
|}




Line 110: Line 111:
* [https://www.eumayors.eu/ Covenant of Mayors Database]
* [https://www.eumayors.eu/ Covenant of Mayors Database]
* [https://www.kaggle.com/search?q=energy Big Data]
* [https://www.kaggle.com/search?q=energy Big Data]
= Dublin Core =
{| class="wikitable"
|+  Simple Dublin core. 15 DC elements with their (shortened) official definitions and suggested interpretations for audiovisual contexts. Source: [https://www.iasa-web.org/tc04/descriptive-metadata-application-profiles-dublin-core-dc IASA]
! DC element name !! DC definition !! Audiovisual interpretation
|-
! Title
| A name given to the resource || The main title associated with the recording
|-
! Subject
| The topic of the resource || Main topics covered
|-
! Description
| An account of the resource || Explanatory notes, interview summaries, descriptions of environmental or cultural context, list of contents
|-
! Creator
| An entity primarily responsible for making the resource || Not authors or composers of the recorded works but the name of the archive
|-
! Publisher
| An entity responsible for making the resource available || Not the publisher of the original document that has been digitized. Typically the publisher will be the same as the Creator
|-
! Contributor
| An entity responsible for making contributions to the resource || Any named person or sound source.Will need suitable qualifier, such as role (e.g. performer, recordist)
|-
! Date
| A point or period of time associated with an event in the lifecycle of the resource || Not the recording or (P) date of the original but a date relating to the resource itself
|-
! Type
| The nature or genre of the resource || The domain of the resource, not the genre of the music. So Sound, not Jazz
|-
! Format
| The file format, physical medium, or dimensions of the resource || The file format, not the original physical carrier
|-
! Identifier
| An unambiguous reference to the resource within a given context || Likely to be the URI of the audio file
|-
! Source
| A related resource from which the described resource is derived || A reference to a resource from which the present resource is derived
|-
! Language
| A language of the resource || A language of the resource
|-
! Relation
| A related resource || Reference to related objects
|-
! Coverage
| The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant || What the recording exemplifies, e.g. a cultural feature such as traditional songs or a dialect
|-
! Rights
| Information about rights held in and over the resource || Information about rights held in and over the resoure
|}

Revision as of 09:18, 16 June 2020


This is the page for the gap analysis.

Tacit knowledge "FAIRification and opening of low carbon energy research data"


Consortium members can add any time, they feel that something is important to note even though it is not mentioned in a standard deliverable. In other words, this page collects uncodified, tacit knowledge. It will help us later to compile suggestions and lessons learned. This kind of knowledge is collected two-fold:

  1. Anytime if someone feels that this should be noted. Please write down: Issue, Date, Author (could also be "anonymous"), the issue described in a few words or maximal lines>
  2. During the final day of workshops

Learning process:

  • People are hesitant to adopt new IT technologies, this is even the case among researchers heavily relying on data, algorithms and collaborative online software (e.g., R, platforms, online conferencing, HPC, ...). The effort to encourage change is not to underestimate. Reasons are several, notably, lack of time and uncertainty about potential benefit as well as overall risk aversion preferences. EERAdata is using the online software "Only Office" to facilitate collaboration (in particular also during the Covid-19 period).


FAIR and open criteria:

  • Consortium members have a fair understanding of what FAIR/O is, but there is little knowledge and/or technical experience on how to approach the FAIRification and opening. All, however, share the view that we are at a critical point in time, where we need to implement these criteria. 
  • To deepen knowledge about FAIR/O criteria, it is useful to test the criteria on a database one is familiar with. For this purpose (and to start brainstorming about the platform), AIT has developed a questionnaire for application in the use cases.

Metadata:

  • A good starting point is to think about metadata and to look into existing metadata concepts in one's field. The first step is to understand that also metadata need to adhere to the FAIR/O principles.
  • The next step is to increase knowledge on IT specific terms, i.e. to understand what the difference is between different metadata frameworks (taxonomy, thesaurus, ontology) as well as classification of metadata (high-level, medium-level, low-level OR administrative, structural and descriptive metadata).  WP 2 being in charge of aligning approaches between use cases, participates in all use case kickoffs to bring everybody on the same page. The presentation is linked with "metadata frameworks".
  • It is useful to supply consortium members with read aheads and watch aheads on metadata to prepare the first EERAdata workshop. The workshop starts applications and discussions in the use cases break out sessions (and bringing insights back to the plenary), using selected databases.


Identified gaps after Workshop 1 (02/06/2020 – 04/06/2020)

This table shows a summary of the specific issues that were identified in Workshop 1. The aim was to categorise different issues to get a better understanding of how to tackle these challenges.
General Issue Specific Issues Results Solutions
Privacy issues and expected disadvantages
  • Not publishing data due to privacy concerns (sensitive data)
  • Data publishing could lead to potential market disadvantages/competition
  • UC2: In case of distribution network data this is relevant
No data published at all (?)
Licensing
  • No licenses available may mean the data is not reusable for the researcher
  • Licenses not clear and accessible
  • Obtaining licenses may result in more effort and costs
Data potentially not reusable Explicitly show licenses for different data, actively encourage licensing
Taxonomy/ontology/common vocabulary and language issues
  • Lack of standardisation
  • Heterogeneous data makes standardisation hard
  • No vocabulary documentation on websites
  • Words used for same term in other languages may differ
  • Databases in other languages than English
Research costs more time (?)
Metadata range
  • Different field require different metadata (potentially very specific)
  • UC3: additional metadata for applications of materials
Data are less useful for the specific field (?)
Linking issues
  • Missing identifiers on websites
  • No linking to source documents and related publications (for contextual knowledge)
  • Identifier not in downloaded data files
  • Possibly need for links to other fields
  • UC3: link between microscopic and macroscopic materials (e.g., turbine blades)
  • Data cannot be connected to the source
  • Makes research more difficult.
(?)
Quality of data
  • No qualitative assessment of the data itself (which may be limited)
  • When the data is collected from different and high number of sources, its reliability decreases
  • UC1:
    • multiplicity and scattered nature of data sources (households, industries, utility companies, municipalities)
    • lack of data availability for time-series
Makes research more difficult (?)
Conducting FAIR assessments
  • Discrepancies between results conducted by humans versus machines
  • Sometimes not even DC standards are met
  • Metadata is not updated
  • Lacking encryption of websites (https)
  • Problems assessing whether metadata will be available after data is unavailable
  • Interface design/layout may be unclear, uncomplete or not intuitive for humans
  • Authentication details (user registration login / good or bad, clarify)
  • Assessment is uncertain (human assessment may need more clarification and understanding)
  • Makes research more time-intensive
(?)
Food complements


Potential Databases in connection with SmartCities


Dublin Core

Simple Dublin core. 15 DC elements with their (shortened) official definitions and suggested interpretations for audiovisual contexts. Source: IASA
DC element name DC definition Audiovisual interpretation
Title A name given to the resource The main title associated with the recording
Subject The topic of the resource Main topics covered
Description An account of the resource Explanatory notes, interview summaries, descriptions of environmental or cultural context, list of contents
Creator An entity primarily responsible for making the resource Not authors or composers of the recorded works but the name of the archive
Publisher An entity responsible for making the resource available Not the publisher of the original document that has been digitized. Typically the publisher will be the same as the Creator
Contributor An entity responsible for making contributions to the resource Any named person or sound source.Will need suitable qualifier, such as role (e.g. performer, recordist)
Date A point or period of time associated with an event in the lifecycle of the resource Not the recording or (P) date of the original but a date relating to the resource itself
Type The nature or genre of the resource The domain of the resource, not the genre of the music. So Sound, not Jazz
Format The file format, physical medium, or dimensions of the resource The file format, not the original physical carrier
Identifier An unambiguous reference to the resource within a given context Likely to be the URI of the audio file
Source A related resource from which the described resource is derived A reference to a resource from which the present resource is derived
Language A language of the resource A language of the resource
Relation A related resource Reference to related objects
Coverage The spatial or temporal topic of the resource, the spatial applicability of the resource, or the jurisdiction under which the resource is relevant What the recording exemplifies, e.g. a cultural feature such as traditional songs or a dialect
Rights Information about rights held in and over the resource Information about rights held in and over the resoure