Gap analysis

From EERAdata Wiki
Revision as of 14:28, 16 June 2020 by Christopherbs (talk | contribs) (Dublin Core: Added attempt to assess impact)
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.


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

The DCMI Metadata Terms lists the current set of the Dublin Core vocabulary. Source: Dublin Core Metadata Initiative
1 abstract 11 contributor 21 extent 31 isReplacedBy 41 publisher 51 tableOfContents
2 accessRights 12 coverage 22 format 32 isRequiredBy 42 references 52 temporal
3 accrualMethod 13 created 23 hasFormat 33 issued 43 relation 53 title
4 accrualPeriodicity 14 creator 24 hasPart 34 isVersionOf 44 replaces 54 type
5 accrualPolicy 15 date 25 hasVersion 35 language 45 requires 55 valid
6 alternative 16 dateAccepted 26 identifier 36 license 46 rights
7 audience 17 dateCopyrighted 27 instructionalMethod 37 mediator 47 rightsHolder
8 available 18 dateSubmitted 28 isFormatOf 38 medium 48 source
9 bibliographicCitation 19 description 29 isPartOf 39 modified 49 spatial
10 conformsTo 20 educationLevel 30 isReferencedBy 40 provenance 50 subject


Category Types:

  • Administrative metadata: who collected, when collected, where etc.
  • Descriptive metadata: what is described by the data
  • Structural metadata: organization of data, file formats


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 Example Category
Title A name given to the resource The main title associated with the recording Descriptive
Subject The topic of the resource Main topics covered Descriptive
Description An account of the resource Explanatory notes, interview summaries, descriptions of environmental or cultural context, list of contents Descriptive
Creator An entity primarily responsible for making the resource Not authors or composers of the recorded works but the name of the archive Administrative
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 Administrative
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) Administrative
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 e.g. energy consumption in 2016 Administrative (?)
Type The nature or genre of the resource The domain of the resource, not the genre of the music. So Sound, not Jazz Descriptive
Format The file format, physical medium, or dimensions of the resource The file format, not the original physical carrier Structural
Identifier An unambiguous reference to the resource within a given context Likely to be the URI of the audio file Structural
Source A related resource from which the described resource is derived A reference to a resource from which the present resource is derived Descriptive
Language A language of the resource A language of the resource e.g. eng, ger, ita Descriptive
Relation A related resource Reference to related objects Descriptive
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 Descriptive
Rights Information about rights held in and over the resource Information about rights held in and over the resoure Administrative
Impact/Exploitation Impact of the data Information about the number of citations and/or accesses Administrative

Attempting to put a value on Impact/Exploitation:

  • ENTSO-E: Found 172 results in Advanced Search (ALL) in Web of Science (WoSc) (16/06/2020). Citations of all these search result add up to 714. This however does not mean, that all search results really explicitly used data from ENTSO-E. Some (for sure, for some were found) only mentioned it saying they adoped workflow etc. from the site.
  • SMARD: Found 82 results in Advanced Search (ALL=(SMARD)) in Web of Science (WoSc) (16/06/2020). However: SMARD is also an acronym for Spinal muscular atrophy with respiratory distress (SMARD). This somewhat complicates results and needs some further discussion. All 82 search results accumumlated 2359 citations themselves.


Example "time-based media: The elements of DC have been expanded to include further properties. These are referred to as DC Terms. A number of these additional elements (‘terms’) will be useful for describing time-based media:
DC Term DC definition Audiovisual interpretation
Alternative Any form of the title used as a substitute or alternative to the formal title of the resource An alternative title, e.g. a translated title, a pseudonym, an alternative ordering of elements in a generic title
Extent The size or duration of the resource File size and duration
extentOriginal The physical or digital manifestation of the resource The size or duration of the original source recording(s)
Spacial Spatial characteristics of the intellectual content of the resource Recording location, including topographical co-ordinates to support map interfaces
Temporal Temporal characteristics of the intellectual content of the resource Occasion on which recording was made
Created Date of creation of the resource Recording date and any other significant date in the lifecycle of the recording


Additional Elements for Energy Domain (Proposal from August)
Date of availability Since wenn is the database available
Information on the number of user (if yes add the number otherwise no)
Number of scientific publications where data is cited/mentioned Check "web of science"
Curation activities Is there versioning and on-going development