Functional specifications - Revision history

Manfred: /* Front end */

2020-11-02T09:20:36Z

Front end

← Older revision		Revision as of 09:20, 2 November 2020
Line 15:		Line 15:

	===Front end===		===Front end===
	Methods: user stories, design thinking, mock-ups, Wiki (~~voting~~)		Methods: user stories, design thinking, mock-ups, Wiki (comments, feedback)
	====Landing page====		====Landing page====
	user authentication; user guide		user authentication; user guide

Manfred: /* Back end */

2020-10-12T12:28:50Z

Back end

← Older revision		Revision as of 12:28, 12 October 2020
Line 63:		Line 63:
	*Interfaces to import metadata from external sources (provided by the Use Cases)		*Interfaces to import metadata from external sources (provided by the Use Cases)
	*Data preparation for front end		*Data preparation for front end
			*User account management
	*User group management		*User group management
	*...		*...

Manfred: /* Platform elements */

2020-10-12T12:25:22Z

Platform elements

← Older revision		Revision as of 12:25, 12 October 2020
Line 20:		Line 20:
	====Community forum====		====Community forum====
	feedback on platform; discussion of content		feedback on platform; discussion of content
	====~~Dashboard~~====
			====Metadata selector====
			*Dashboard structure
			*linking to external databases
	*identification of relevant databases using metadata		*identification of relevant databases using metadata

			====Display, analysis & visualization====
			*Dashboard structure
	*direct access to selected databases		*direct access to selected databases
			*display of tabular data from supported databases
	*integrated applications for basic analytic features		*integrated applications for basic analytic features

	~~====Display, analysis & visualization====~~
	====Session logging====		====Session logging====
	for later performance monitoring		*utilizing cookies for collecting session history for later performance monitoring
			*GDPR compliance (opt-in, request for stored data, request to delete PII)

	===Processing and storage device===		===Processing and storage device===
Line 70:		Line 77:
	*Migration and future maintenance		*Migration and future maintenance
	*…		*…


	==Methods and tools==		==Methods and tools==

Manfred: /* Dashboard */

2020-10-12T12:06:06Z

Dashboard

← Older revision		Revision as of 12:06, 12 October 2020
Line 21:		Line 21:
	feedback on platform; discussion of content		feedback on platform; discussion of content
	====Dashboard====		====Dashboard====
	~~queries~~		*identification of relevant databases using metadata
			*direct access to selected databases
			*integrated applications for basic analytic features

	====Display, analysis & visualization====		====Display, analysis & visualization====
	====Session logging====		====Session logging====

Manfred: /* Back end */

2020-10-12T12:01:57Z

Back end

← Older revision		Revision as of 12:01, 12 October 2020
Line 53:		Line 53:
	*Interfaces to import metadata from external sources (provided by the Use Cases)		*Interfaces to import metadata from external sources (provided by the Use Cases)
	*Data preparation for front end		*Data preparation for front end
	*…		*User group management
			*...
	Methods: software development, establishment of communication channels with database holders		Methods: software development, establishment of communication channels with database holders


	===Software system requirements===		===Software system requirements===

Manfred: /* Metadata database model */

2020-10-05T16:45:31Z

Metadata database model

← Older revision		Revision as of 16:45, 5 October 2020
Line 33:		Line 33:
	In the following figure, we sketch how metadata describing the thematic character of external databases may be harmonized for use in the EERAdata platform. A similar strategy could also be used to harmonize the metadata for the specific records in the databases; this would be conceptually similar, but with a more complicated structure to the records.		In the following figure, we sketch how metadata describing the thematic character of external databases may be harmonized for use in the EERAdata platform. A similar strategy could also be used to harmonize the metadata for the specific records in the databases; this would be conceptually similar, but with a more complicated structure to the records.

	~~''Insert figure here''~~		[[file:DBstructure.png\|800px]]

	Three external databases are considered, and termed DB1, DB2, and DB3. They are each described in terms of a set of thematic classes following some standard classification, given in terms of persistent identifiers (pIDs) for the appropriate classes. DB1 and DB2 use the same standardization system, providing pIDs (Class-std1-ID) for the appropriate classes. DB3 uses a second standardization system, providing pIDs (Class-std2-ID) for its corresponding classes. We cannot assume the two systems to be commensurable.		Three external databases are considered, and termed DB1, DB2, and DB3. They are each described in terms of a set of thematic classes following some standard classification, given in terms of persistent identifiers (pIDs) for the appropriate classes. DB1 and DB2 use the same standardization system, providing pIDs (Class-std1-ID) for the appropriate classes. DB3 uses a second standardization system, providing pIDs (Class-std2-ID) for its corresponding classes. We cannot assume the two systems to be commensurable.

Manfred: /* Methods and tools */

2020-10-05T16:40:21Z

Methods and tools

← Older revision		Revision as of 16:40, 5 October 2020
Line 80:		Line 80:
	Design suggestions are posted on the Wiki for voting and feedback within the project community.		Design suggestions are posted on the Wiki for voting and feedback within the project community.

	===~~Collection of user requirements~~===		===User stories===

	As a first step, the use case leaders and other use-case members are involved in formulating the needs and requirements. As an important tool, we plan to use '''user stories''' to be provided by them or other stakeholders from the energy research community. User stories put features in the context of what the user needs to accomplish. They describe the task or feature, but not how the developers should implement it. First step: invite Use Case leaders and members to collect user stories on the Wiki. Second step: approach external stakeholders for user stories (database holders, interoperability community…).		As a first step, the use case leaders and other use-case members are involved in formulating the needs and requirements. As an important tool, we plan to use '''user stories''' to be provided by them or other stakeholders from the energy research community. User stories put features in the context of what the user needs to accomplish. They describe the task or feature, but not how the developers should implement it. First step: invite Use Case leaders and members to collect user stories on the Wiki. Second step: approach external stakeholders for user stories (database holders, interoperability community…).

Manfred: /* Processing and storage device */

2020-10-05T16:38:56Z

Processing and storage device

← Older revision		Revision as of 16:38, 5 October 2020
Line 27:		Line 27:

	===Processing and storage device===		===Processing and storage device===
			====Metadata database model====

			Methods: Design thinking, EERAdata Workshop 2, Wiki-Platform interface

	In the following figure, we sketch how metadata describing the thematic character of external databases may be harmonized for use in the EERAdata platform. A similar strategy could also be used to harmonize the metadata for the specific records in the databases; this would be conceptually similar, but with a more complicated structure to the records.		In the following figure, we sketch how metadata describing the thematic character of external databases may be harmonized for use in the EERAdata platform. A similar strategy could also be used to harmonize the metadata for the specific records in the databases; this would be conceptually similar, but with a more complicated structure to the records.

			''Insert figure here''

	Three external databases are considered, and termed DB1, DB2, and DB3. They are each described in terms of a set of thematic classes following some standard classification, given in terms of persistent identifiers (pIDs) for the appropriate classes. DB1 and DB2 use the same standardization system, providing pIDs (Class-std1-ID) for the appropriate classes. DB3 uses a second standardization system, providing pIDs (Class-std2-ID) for its corresponding classes. We cannot assume the two systems to be commensurable.		Three external databases are considered, and termed DB1, DB2, and DB3. They are each described in terms of a set of thematic classes following some standard classification, given in terms of persistent identifiers (pIDs) for the appropriate classes. DB1 and DB2 use the same standardization system, providing pIDs (Class-std1-ID) for the appropriate classes. DB3 uses a second standardization system, providing pIDs (Class-std2-ID) for its corresponding classes. We cannot assume the two systems to be commensurable.
Line 34:		Line 40:

	The correspondence tables allow us to describe the external databases in a consistent fashion using the internal standard for the platform. Needed detail is provided internally, e.g., giving a short class name and a description as shown in the figure. Beyond using the classes as a nomenclature for thematic content, ontological relations between the classes can be expressed, e.g., as a Class-hierarchy specifying which classes have others as subclasses, shown in the figure as pairings of pIDs for the classes along with their separation in the hierarachy. Crucially, it is not necessary to use the ontological structures of the external databases, although they must be accounted for in preparing the correspondence tables.		The correspondence tables allow us to describe the external databases in a consistent fashion using the internal standard for the platform. Needed detail is provided internally, e.g., giving a short class name and a description as shown in the figure. Beyond using the classes as a nomenclature for thematic content, ontological relations between the classes can be expressed, e.g., as a Class-hierarchy specifying which classes have others as subclasses, shown in the figure as pairings of pIDs for the classes along with their separation in the hierarachy. Crucially, it is not necessary to use the ontological structures of the external databases, although they must be accounted for in preparing the correspondence tables.

			===='Data' database====
			The EERAdata platform is intended to build on external resources as far as possible, minimizing internal storage (and computation requirements. The complexity will depend on the visualization requirements that emerge in the course of the project. At the current stage, it is not possible to be more specific without some external databases in mind.
			====Database interface====
			to support standardization and harmonization process
			====Open core search====
			functionality to support the establishment of ontologies?
			====Evaluation of session logs====

	===Back end===		===Back end===

Manfred: /* Processing and storage device */

2020-10-05T16:31:43Z

Processing and storage device

← Older revision		Revision as of 16:31, 5 October 2020
Line 27:		Line 27:

	===Processing and storage device===		===Processing and storage device===
			In the following figure, we sketch how metadata describing the thematic character of external databases may be harmonized for use in the EERAdata platform. A similar strategy could also be used to harmonize the metadata for the specific records in the databases; this would be conceptually similar, but with a more complicated structure to the records.

			Three external databases are considered, and termed DB1, DB2, and DB3. They are each described in terms of a set of thematic classes following some standard classification, given in terms of persistent identifiers (pIDs) for the appropriate classes. DB1 and DB2 use the same standardization system, providing pIDs (Class-std1-ID) for the appropriate classes. DB3 uses a second standardization system, providing pIDs (Class-std2-ID) for its corresponding classes. We cannot assume the two systems to be commensurable.

			Further, we cannot assume that either system is commensurable with the standardization system adopted for the EERAdata platform. Thus, instead of directly using the standards from the external databases, we harmonize the external standards to that used by the EERAdata platform. This is shown as the tables Std1-harmonization and Std2-harmonization, which constitute correspondence tables between the external pIDs and the pIDs used internally by EERAdata (EERAdata-std-ID). The correspondence tables must accurately relate standards that may be at different levels of precision and with different approaches to classification. It is thus essential that the tables are constructed with input from domain experts.

			The correspondence tables allow us to describe the external databases in a consistent fashion using the internal standard for the platform. Needed detail is provided internally, e.g., giving a short class name and a description as shown in the figure. Beyond using the classes as a nomenclature for thematic content, ontological relations between the classes can be expressed, e.g., as a Class-hierarchy specifying which classes have others as subclasses, shown in the figure as pairings of pIDs for the classes along with their separation in the hierarachy. Crucially, it is not necessary to use the ontological structures of the external databases, although they must be accounted for in preparing the correspondence tables.

	===Back end===		===Back end===

Manfred at 16:29, 5 October 2020

2020-10-05T16:29:47Z

← Older revision		Revision as of 16:29, 5 October 2020
Line 10:		Line 10:
	* '''To specify technical implementation options.''' A Software Requirements Specification (SRS) is a description of a software system to be developed. Typically, it is written by a technical writer, a systems architect, or a software programmer. Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating risks, schedules, and, in our case, future maintenance issues. I		* '''To specify technical implementation options.''' A Software Requirements Specification (SRS) is a description of a software system to be developed. Typically, it is written by a technical writer, a systems architect, or a software programmer. Software requirements specification is a rigorous assessment of requirements before the more specific system design stages, and its goal is to reduce later redesign. It should also provide a realistic basis for estimating risks, schedules, and, in our case, future maintenance issues. I

	Thus, three perspectives are considered~~: User~~ needs ~~– Software~~ design issues ~~– Software implementation plan~~. ~~These three aspects are considered using~~ the ~~following definitions from~~ software development ~~which~~ are ~~adapted~~ to ~~EERAdata~~ needs.		Thus, in the following, three perspectives are considered - user needs, software design- and software implementation issues - in the development of the platform elements and in the use of the methods and tools.

			==Platform elements==

			===Front end===
			Methods: user stories, design thinking, mock-ups, Wiki (voting)
			====Landing page====
			user authentication; user guide
			====Community forum====
			feedback on platform; discussion of content
			====Dashboard====
			queries
			====Display, analysis & visualization====
			====Session logging====
			for later performance monitoring

			===Processing and storage device===

			===Back end===
			*Interfaces to external resources (APIs, …); communication with platform owners, support by Use Case Leaders required
			*Interfaces to import metadata from external sources (provided by the Use Cases)
			*Data preparation for front end
			*…
			Methods: software development, establishment of communication channels with database holders


			===Software system requirements===
			*Usability
			*Graphic design
			*Reliability
			*Availability
			*Adherence to IPRs
			*Data protection
			*Security
			*Migration and future maintenance
			*…


			==Methods and tools==
			To collect expectations and needs, we must account for different perspectives:
			# energy research expertise from use cases & gap analysis;
			# data science expertise from FAIR/O community; and
			# process expertise from standardisation community


			===Design thinking===
			Which tools will we use to create the mock-ups?
			Design suggestions are posted on the Wiki for voting and feedback within the project community.

			===Collection of user requirements===

			As a first step, the use case leaders and other use-case members are involved in formulating the needs and requirements. As an important tool, we plan to use '''user stories''' to be provided by them or other stakeholders from the energy research community. User stories put features in the context of what the user needs to accomplish. They describe the task or feature, but not how the developers should implement it. First step: invite Use Case leaders and members to collect user stories on the Wiki. Second step: approach external stakeholders for user stories (database holders, interoperability community…).

			===EERAdata Workshops===

			===Community forum===

			===EERAdata Wiki===