city data via data API’s 5. Platform quickly process user’s request for data publication 6. Platform validates data submitted o If valid data, platform acknowledges data publication has been successful o If non-valid data, platform shows error message and returns to step 1 End of data publication Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 18 2.3.3 Use Case: Manage Resources ID: UC3 Refines: GOAL 1: City data is collected in an intelligent manner Pre-condition: User successfully authenticates in the platform Actors: City data publisher Rationale: Manage resources provides the services and functions for updating, maintaining and accessing both data and metadata, as well as tracking the usage of resources by users. Ideally the owners of the resources should be the only authorised user to manage resources, and other authorised users can track the usage of the resources in the platform. The platform must provide a database update response indicating the status of the update, avoid update errors to be propagated in the platform, and should keep an audit trail of all actions to enable rollback. Data usage tracking includes performing queries on the data management data to generate result sets, and producing reports from these result sets. Specialised Use Cases: The Use Case Manage Resources data is distinguished into two specialised Use Cases: “User manages resources (UC3.1)” and “User tracks resources usage (UC3.2)”. Subordinated Use Cases: “Transmit Data (UC5)” Refines into requirements: FREQ.27 to FREQ.25. Specialised Use Cases Basic Interactions and Responses 1. Platform provides user with an interface for resources management (e.g. data and metadata, data usage) 2. User chooses to edit or delete data 3. If edit, user revise metadata associated with the data (license, provenance, ownership, access-control, semantics); UC3.1. User manages 4. If delete, user selects dataset(s) to be removed resources 5. User confirms action 6. Platform quickly process user’s request 7. Platform confirms execution of request o If valid request, platform acknowledges request has been processed successfully o If non-valid request, platform returns to step 1. 8. End of resources management 1. Platform provides user with an interface for resources management (e.g. data and metadata, data usage) 2. User chooses to visualise usage information of a dataset UC3.2. User tracks 3. Platform quickly process user’s request for data usage resources usage information 4. Platform provides user with statistical information about data usage and data users anonymised information 5. End of data usage tracking. 2.3.4 Functional Requirements Req. ID UC. ID Description Priority Domain Societal Needs, FREQ.1 UC1 Allow data publishers to register to submit data for publication Must Platform Tracks data publication agreements between Data and Platform Business Needs, FREQ.2 UC1 Must Providers Platform Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 19 Store terms of agreements, and use them to monitor/review/process FREQ.3 UC1 Must City Data, Platform data submissions. Able to add and edit terms of agreement, based on access of level of Business Needs, FREQ.4 UC1 Must user. Platform FREQ.5 UC1 Data publications are managed and monitored Must City Data, Platform Allow authenticated users from across different organisations to City Data, Platform, FREQ.6 UC2 Must publish city data Business Needs Provide authorization mechanisms for users and sensors to publish FREQ.7 UC2 Must City Data, Platform city data City Data, Platform, FREQ.9 UC2 Provide mechanisms for static data publication Must Business Needs City Data, Platform, FREQ.10 UC2 Provide mechanisms for real-time data publication Must Business Needs FREQ.11 UC2 Enable the publication of metadata Must City Data, Platform FREQ.12 UC2 Maintain temporal information about the data Must City Data, Platform FREQ.13 UC2 Support sensory data collection Must City Data, Platform FREQ.14 UC2 Accepts content in numerous file types/formats Must City Data, Platform Prompts a request for resubmission to the data provider if an error of FREQ.15 UC2 Must City Data, Platform data transmission or receipt occurs FREQ.16 UC2 Enable the semantic description of connected devices Must City Data, Platform FREQ.17 UC2 Gather data from authenticated and authorized devices Must City Data, Platform FREQ.18 UC2 Validates automatically the successful transfer of the data Must City Data, Platform FREQ.19 UC2 Performs virus checking on data Must City Data, Platform Verifies the validity of the submission based on submitter, expected FREQ.20 UC2 Must City Data, Platform format, data quality, and completeness Platform should have built-in checks on the incoming metadata. Data FREQ.21 UC2 not containing the minimally defined set of attributes should be Must City Data, Platform returned to the publisher for metadata enhancement. System should have a user-friendly method of mapping non-standard FREQ.22 UC2 Should City Data, Platform metadata elements into approved standard elements. Once ingested, metadata should be stored in a single common format. FREQ.23 UC2 This format should be one that ensures against data loss, and allows a Must City Data, Platform variety of access/distribution options Data in the repository shall have sufficient technical metadata to FREQ.24 UC2 assure functionality (e.g. viewing and display) to ensure accessibility Must City Data, Platform and reusability. Allows publishers to display and perform manual/visual quality control Business Needs, City FREQ.25 UC2 Could assurance via a user-friendly GUI Data, Platform Business Needs, City FREQ.26 UC2 Any errors shall prompt a request for resubmission of data Should Data, Platform FREQ.27 UC3 Enable data providers to manage their resources Must Business Needs A minimal set of identifying information/metadata concerning data Business Needs, FREQ.28 UC3 Must publication submission must be recorded Platform Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 20 Stores and tracks versions of data. Links /connections between FREQ.29 UC3 Must City Data, Platform versions are created and maintained Give service and data providers access to anonymized data of the Business Needs FREQ.30 UC3 Should subscribers of their data or services City Data, Platform, FREQ.31 UC3 Enable data providers to maintain and repair data and metadata Should Business Needs Tracks data publication agreements between Data and Platform Business Needs, FREQ.32 UC3 Must Providers Platform Store terms of agreements, and use them to monitor/review/process FREQ.33 UC3 Must City Data, Platform data submissions. Able to add and edit terms of agreement, based on access of level of Business Needs, FREQ.34 UC3 Must user. Platform FREQ.35 UC3 Submission volumes and schedules are managed and monitored Must City Data, Platform 2.4 SUB-GOAL 2: City data is managed in a safe and intelligent manner Rationale: The urban platform enables users to publish, consume and commercialise data, as well as deploy and manage services all in a secure and privacy protected manner. Achieve [City data is exploited to its full effect] Goal co-ena bles Maintain [Resources are managed in a safe and intelligent manner] S ub-Goal 1 Achieve [Store Data] Achieve [Transmit Data] Achieve [Manage Infrastructure] UC4 UC5 UC6 Figure 6. Sub-Goal 2 “City data is managed in a safe and intelligent manner” refinement. Drivers: Ensure data is secured and the identity of users are preserved Actions: For Sub-Goal 2 to be maintained in the long-run it requires the efficient realisation of use cases: “Store City Data” and “Retrieve and Transmit City Data”, as shown in Figure 6. 2.4.1 Use Case: Store City Data ID: UC4 Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner Pre-condition: Data is successfully published in the platform Actors: Urban Platform Rationale: When data is successfully submitted (either via APIs or manual upload), it is processed/prepared for storage into the platform’s database. This procedure will include the Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 21 generation of unique identifiers to the database, enrichment with ontologies (when applicable), encrypted (when applicable), signed with digital certificates (when applicable) to ensure that the data conforms to the platform data formatting, standards, security and regulation. Data may be converted to accepted formats, as needed (e.g. graph model). A primary goal of the conversion of content for the platform is the preservation of the content. Priority will be given to preserving the data accordingly to the policies defined in section (2.6.2). Access-control levels and license models are associated to data which is subject to restrictions relating to access and conditions of use. Refines into requirements: FREQ 28 – FREQ 39. Use Case Basic Interactions and Responses 1. Platform mechanisms converts submitted data into a standard format 2. Security enforcement (e.g. anonymisation, cryptography) is placed on sensitive information. UC4. Store City 3. Platform associates with datasets the access-control definitions set by Data owner of resources. 4. Data is enriched with semantics and is associated with other datasets 5. Platform stores data in a scalable and secure database. 6. End of data storage. 2.4.2 Use Case: Transmit Data ID: UC5 Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner Pre-condition: Data is successfully published in the platform Actors: Urban Platform Rationale: The platform accepts data retrieval request, validates user’s rights to access the data, retrieves city data from data storage, and moves a copy of the data to the relevant platform component for further processing. If special processing is required, the retrieval function accesses data in staging storage and applies the requested processes. The types of operations, which may be carried out, include sub-sampling in temporal or spatial dimensions, conversions between different data types or output formats, and other specialized processing (e.g., data visualisation). Once it is finalised data will be sent to the appropriate delivery channels (e.g. API’s, GUI). It also encompasses function to verify corruption during any internal data transfer. This function requires that all hardware and software within the platform provide notification of potential errors and that these errors are routed to standard error logs that are checked by the Platform Provider. Refines into requirements: FREQ 40 to 54. 2.4.3 Use Case: Manage Infrastructure ID: UC6 Refines: SUB-GOAL 2: City data is managed in a safe and intelligent manner Pre-condition: The platform is available Actors: Urban Platform Rationale: Manage infrastructure provides the services and functions for the overall operation of the urban platform. Administration functions include monitoring quality of service agreements, auditing data publication to ensure that they meet archive standards, and maintaining configuration management of system hardware and software. In overall, it provides system engineering functions to monitor and improve platform operations, and to inventory, report on, and migrate/update the contents of the platforms’ databases. Refines into requirements: FREQ 55 to 62. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 22 Use Case Basic Interactions and Responses 1. Platform keeps monitoring services at run-time to ensure operation and integrity of city data o If system failure, the platform activates mechanisms for recovery UC6. Manage based on pre-defined rules Infrastructure o Platform logs issue and issue alert messages to platform providers 2. Platform logs operation capabilities (e.g. performance, mean of time failure, issues, etc.) 2.4.4 Functional Requirements Req. ID UC. ID Description Priority Domain A minimal set of identifying information/metadata concerning data Business Needs, FREQ.28 UC4 Must publication submission must be recorded. Platform Stores and tracks versions of data. Links /connections between FREQ.29 UC4 Must City Data, Platform versions are created and maintained. FREQ.30 UC4 Converts data to accepted file formats Must City Data, Platform Keep sensitive information secured and accessible only to authorized FREQ.31 UC4 Must City Data, Platform users FREQ.32 UC4 Keep user’s personal information protected Should City Data, Platform FREQ.33 UC4 Keep city data and meta-data secured Must Platform Needs FREQ.34 UC4 Enable privacy preserving mechanisms associated to data Must Platform Needs FREQ.35 UC4 Model data in accordance with defined standards Must City Data, Platform FREQ.36 UC4 Support the use of ontologies and semantic modelling of city data Could City Data FREQ.37 UC4 Support database-level provenance annotation Should City Data FREQ.38 UC4 Support data-level provenance annotation Should City Data FREQ.39 UC4 Enable data to be encrypted Should Platform Needs System must have the ability to search and display metadata, preferably City Data, Platform FREQ.40 UC5 in a user-conformable, human readable display as well as in its native Must Needs format for machine harvesting and manipulation. Controls access to data in the repository based on multiple permission City Data, Platform FREQ.41 UC5 levels. These permission levels determine the create/edit/read/delete Should Needs privileges granted users. Access rights and conditions of use will be held for each data and its City Data, Platform FREQ.42 UC5 Should related metadata. Needs Access rights and conditions can be inherited from a parent data to any City Data, Platform FREQ.43 UC5 Could data designated as a child data (derived information). Needs Access rights and conditions of use will be machine readable and City Data, Platform FREQ.44 UC5 Should actionable. Needs Access mechanisms must be sufficiently granular to allow the Business Needs, City FREQ.45 UC5 identification of individual users, in order to maintain audit logs of actions Should Data, Platform performed by users. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 23 Maintains the integrity of the database which contains both metadata FREQ.46 UC5 and system information. Must Platform Needs Provides internal validation such as referential integrity of the contents of City Data, Platform FREQ.47 UC5 the database. Must Needs Creates and maintains schema definitions required to support data FREQ.48 UC5 management functions. Must Platform Needs Monitors and ensures that data and metadata are not corrupted during FREQ.49 UC5 transfers. Must Platform Needs Provides statistically acceptable assurance that no components of the FREQ.50 UC5 data are corrupted during any internal data transfer. Must Platform Needs Performs routine and special data integrity checking for each dataset FREQ.51 UC5 and generates error reports. Must Platform Needs Provides disaster recovery capabilities including data backup, off-site FREQ.52 UC5 data storage, data recovery, etc. Must Platform Needs Refresh/replace data without service interruption, and update FREQ.53 UC5 corresponding metadata as appropriate. Must Platform Needs Ensure that any associated unique identifiers of the updated data are not FREQ.54 UC5 altered. Must Platform Needs Audits submissions to ensure that they meet archive/repository FREQ.55 UC6 standards. Must Platform Needs Maintains configuration management of the system hardware and FREQ.56 UC6 software. Must Platform Needs Has capability to inventory, report on and migrate the contents of the FREQ.57 UC6 repository. Must Platform Needs FREQ.58 UC6 Ensures data integrity for version upgrades and format migration. Must Platform Needs FREQ.59 UC6 Monitors functionality of the entire repository. Must Platform Needs FREQ.60 UC6 Maintains integrity of system configuration. Must Platform Needs Audits system operations, performance and usage. FREQ.61 UC6 Must Platform Needs Provides platform performance information and database holdings FREQ.62 UC6 inventory reports Must Platform Needs 2.5 SUB-GOAL 3: City data is orchestrated in a marketplace Rationale: The urban platform enables users to consume and publish data in a secure and privacy protected manner. Drivers: Ensure data is secured and the identity of users are preserved Actions: For Sub-Goal 3 to be maintained in the long-run it requires the efficient realisation of use cases: “Commercialise City Data” and “Commercialise Data Services”, as shown in Figure 7. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 24 Achieve [City data is exploited to its full effect] Goal co-ena bles Maintain [City data is orchestrated in a marketplace] S ub-Goal 3 Achieve [Commercialise Data Achieve [Commercialise City Data] Services] UC7 UC8 Figure 7. Sub-Goal 3 “City data is orchestrated in a marketplace” refinement. 2.5.1 Use Case: Commercialise City Data ID: UC7 Refines: SUB-GOAL 3: City data is orchestrated in a marketplace Pre-condition: Data is successfully published in the platform, both publisher and consumers of city data are authenticated in the platform, and there are billing capabilities available. Actors: Data Publishers, Data Consumers Rationale: The providers of city data can commercialise city data based on the policies and financial models defined in the platform. After publishing their data, publishers can define which data can be available as open data and which data should be available with the payment of a subscription fee. Once publishers define which data is to be commercially exploited, the platform will associate the data with their respective financial models and let it ready for subscription. City data consumer chooses which data to purchase and is redirected to a billing interface where the subscription payment is taken. The platform must provide an update response indicating the status of the payment. If successful, data is ready available to be consumed by humans and machines, otherwise the user can re-try the payment or cancel transaction. Commercialise city data also involves the function of managing commercial data. It provides services and functions for updating, maintaining and accessing both data and its respective commercial transactions. Furthermore, it enables data providers to track the usage of commercial data by users. Ideally the owners of the data should be the only authorised user to manage resources, and other authorised users can track the usage of the data in the platform. Data usage tracking includes performing queries on the data management data to generate result sets, and producing reports from these result sets. Data consumers are provided with functions which enable them to manage their subscriptions and financial transactions on the platform. These functions include updating, maintaining and accessing financial transactions. For all these functions and services, the platform must provide a database update response indicating the status of the update, avoid update errors to be propagated in the platform, and should keep an audit trail of all actions to enable rollback. Specialised Use Cases: The Use Case Commercialise City Data is distinguished into four specialised Use Cases: “Commercialise Data (UC7.1)”, “Consume Commercial City Data (UC7.2)”, “Manage Commercial Data (UC7.3)” and “Manage Data Subscription (UC7.4)”. Refines into requirements: FREQ 63 to 68. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 25 Use Case Basic Interactions and Responses 1. User selects the data to be commercialised 2. User selects the commercial model for data consumption UC7.1. 3. Platform validates selection Commercialise 4. Platform associates data to subscription model Data 5. Platform releases data for commercial exploitation in the marketplace 6. End of data commercialisation set up. 1. User selects the data to be subscribed to 2. User request subscription to data UC7.2. 3. Platform validates selection Consume 4. Platform redirects user to billing system Proprietary 5. Billing system deals with user request Data o If successful, user is redirected to a GUI where data is ready to use o If unsuccessful, user can try payment again or cancel request 2. End of data subscription. 1. Platform provides user with an interface for commercial data management 2. User chooses to edit or delete commercial data o If edit, user revise commercial models, licenses, access-control, semantics; o If delete, user selects dataset(s) to be removed (following policies UC7.3. Manage defined in the platform for data removal) commercial 3. User confirms action Data 4. Platform promptly process user’s request 5. Platform confirms execution of request o If valid request, platform acknowledges request has been processed successfully o If non-valid request, platform returns to step 1. 6. End of resources management 1. Platform provides user with an interface for data subscription management 2. User chooses to edit or cancel data subscription o If edit, user revise payment and subscription timeframe; o If cancel, user selects dataset(s) to have subscription cancelled UC7.4. Manage (following policies defined in the platform for data subscription) data 3. User confirms action subscription 4. Platform promptly process user’s request 5. Platform confirms execution of request o If valid request, platform updates acknowledges request has been processed successfully o If non-valid request, platform returns to step 1. 6. End of data subscription management 2.5.2 Use Case: Commercialise Data Services ID: UC8 Refines: SUB-GOAL 3: City data is orchestrated in a marketplace Pre-condition: Data is successfully published in the platform, both publisher and consumers of city data are authenticated in the platform, and there are billing capabilities available. Actors: Data Service Providers, Data Publishers and Consumers Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 26 Rationale: After deploying data services in the platform, the providers of data services can choose to commercialise services based on the policies and financial models defined in the platform. Once data service providers define which service(s) is (are) to be commercially exploited, the platform will associate the services with their respective financial models and let available in the platform applications module ready for use. User (either publisher or consumer) chooses which data services to use, and in case a charged service is selected the platform redirects the user to a billing interface where the payment is taken. The platform must provide an update response indicating the status of the payment. If successful, service is ready available to be used, otherwise the user can re-try the payment or cancel transaction. Note that data service owners should be able to waive the payment of tariff to certain users’ categories. Data services providers are offered with functions to manage their commercial services. The platform provides functions for updating, maintaining and accessing both service and its respective commercial transactions. Furthermore, it enables data services providers to track the usage of services by users. Services usage tracking includes performing queries on the platform to generate result sets, and producing reports from these result sets. The consumers of data services are provided with functions which enable them to manage their subscriptions and financial transactions. These functions include updating, maintaining and accessing financial transactions. For all these functions and services, the platform must provide a database update response indicating the status of the update, avoid update errors to be propagated in the platform, and should keep an audit trail of all actions to enable rollback. Specialised Use Cases: The Use Case Commercialise Data Services is distinguished into four specialised Use Cases: “Commercialise Data Services (UC8.1)”, “Consume Data Services (UC8.2)”, “Manage Commercial Services (UC8.3)” and “Manage Services Subscription (UC8.4)”. Refines into requirements: FREQ 68 to 73. Use Case Basic Interactions and Responses 1. User selects the data services to be commercialised 2. User selects the commercial model for data service usage based on the category of users UC8.1. 3. Platform validates selection Commercialise 4. Platform associates data services to subscription model Data Services 5. Platform enables data service to be commercially exploited in the marketplace 6. End of services commercialisation set up. 1. User selects the data service to be subscribed to 2. User request subscription to service 3. Platform validates selection UC8.2. 4. Platform validates user’s category its respective commercial models Consume Data 4. If applicable, platform redirects user to billing system Services 5. Billing system deals with user’s request o If successful, user is redirected to a GUI where data is ready to use o If unsuccessful, user can try payment again or cancel request 6. End of data subscription. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 27 1. Platform provides user with an interface for commercial data management 2. User chooses to edit or delete commercial data o If edit, user revise commercial models, licenses, access-control, semantics; o If delete, user selects dataset(s) to be removed (following policies UC8.3. Manage defined in the platform for data removal) commercial 3. User confirms action services 4. Platform promptly process user’s request 5. Platform confirms execution of request o If valid request, platform acknowledges request has been processed successfully o If non-valid request, platform returns to step 1. 6. End of resources management 1. Platform provides user with an interface for data subscription management 2. User chooses to edit or cancel data subscription o If edit, user revise payment and subscription timeframe; o If cancel, user selects dataset(s) to have subscription cancelled UC8.4. Manage (following policies defined in the platform for data subscription) services 3. User confirms action subscription 4. Platform promptly process user’s request 5. Platform confirms execution of request o If valid request, platform updates acknowledges request has been processed successfully o If non-valid request, platform returns to step 1. 6. End of data subscription management 2.5.3 Functional Requirements Req. ID UC. ID Description Priority Domain City Data, Platform, FREQ.63 UC7 Support the commercialization of city data Should Business Needs City Data, Platform, FREQ.64 UC7 Enable users to subscribe to city data through the payment of a tariff Should Business Needs City Data, Platform, FREQ.65 UC7 Enable users to manage their data subscriptions Should Business Provide platform providers mechanisms to define the terms and FREQ.66 UC7 Must Platform Needs conditions for platform data usage Enable data providers to manage the subscription models of their City Data, Platform, FREQ.67 UC7 Should data Business UC7/ City Data, Platform, FREQ.68 Utilise secure and reliable billing and payment management systems Must UC8 Business City Data, Platform, FREQ.69 UC8 Support the commercialization of data services Should Business Needs Enable data providers to manage the commercial models of their City Data, Platform, FREQ.70 UC8 Should services Business Needs Provide service providers mechanisms to define the terms and City Data, Platform, FREQ.71 UC8 Should conditions of platform services Business Needs Allow users to pay a tariff for using certain advanced services (e.g. City Data, Platform, FREQ.72 UC8 Should Data manipulation, enrichment) Business Needs City Data, Platform, FREQ.73 UC8 Enable users to manage their data services subscriptions Should Business Needs Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 28 2.6 SUB-GOAL 4: City data is offered in an accessible manner Rationale: The urban platform provides city data in both human and machine (e.g. sensors, actuators, systems) readable and understandable formats. Drivers: Ensure data understandability and machine-to-machine data transaction. Actions: For Sub-Goal 3 to be maintained in the long-run it requires the efficient realisation of use cases: “Register Consumer”, “Discover City Data”, and “Consume City Data” as shown in Figure 8. Achieve [City data is exploited to its full effect] Goal co-ena bles Maintain [City data is offered in an accessible manner] S ub-Goal 1 Achieve [Register Consumer] Achieve [Discover City Data] Achieve [Consume City Data] UC9 UC10 UC11 Figure 8. Sub-Goal 4 “City data is offered in an accessible manner” refinement. 2.6.1 Use Case: Register Data Consumer ID: UC9 Refines: SUB-GOAL 4: City data is offered in an accessible manner Pre-condition: User is not logged in the platform Actors: Data Consumers Rationale: Data Consumers can register in the platform and request approval to consume city data via GUI or APIs. They provide valid registration details (to be defined) and wait for platform to confirm their registration. Users must accept the terms and conditions of platform usage and define how their personal data can be used by the Platform Owner. Users can manage and alter their registration information at any time they want to. Refines into requirements: FREQ 64. Use Case Basic Stimulus and Responses 1. The platform prompts the user for a username and password or register new account. 2. The user selects registration option. 3. The platform prompts user for data consumer registration information UC1. Register 4. The user enters in their information. Consumer 5. Platform verifies information and creates account. o If non-valid information, platform shows error message and returns to step 1. 6. Platform acknowledges registration has been successful 7. End of registration Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 29 2.6.2 Use Case: Discover City Data ID: UC10 Refines: SUB-GOAL 4: City data is offered in an accessible manner Pre-condition: User has access to either platform GUI or API Actors: Data Consumers Rationale: Data Consumers can register in the platform and request approval to consume city data via GUI or APIs. They provide valid registration details (to be defined) and wait for platform to confirm their registration. Refines into requirements: FREQ 64. Use Case Basic Stimulus and Responses 1. Users access specialised data query end-points (e.g. SPARQL) 2. Users provides information for pre-defined parameters for search 3. Users request data search 4. Platform quickly process users request for data