harmonised way full effect User manages resources Manage Resources UC3 City Data Publisher User tracks resources usage Store City Data UC4 2. City data is managed in a safe Transmit Data UC5 - Management Systems and intelligent manner Manage Infrastructure UC6 Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 15 City Data Publisher Set commercial city data Platform Provider Subscribe to proprietary data City Data Consumer Commercialise City UC7 Data Manage commercial data City Data Publisher 3. City data is Manage data subscription City Data Consumer orchestrated in a Data Services Provider market place Set commercial data services Platform Provider Subscribe to commercial services Data Services Consumer Commercialise Data UC8 Services Manage commercial services Data Services Provider Manage services subscription Data Services Consumer UC9 Register in the Platform City Data Consumer - 4. City data is Discover City Data City Data Consumer UC10 offered in an User consumes city data via data accessible manner API’s Consume City Data UC11 City Data Consumer User downloads datasets 5. User’s Data Services Provider Deploy Data Services UC12 experience is Platform Provider enhanced by the Manage Services UC13 - Data Services Provider provision of value- added services Utilise Data Services UC14 City Data Consumer 2.3 SUB-GOAL 1: City data is collected in an intelligent manner Description: The urban platform enables the owners of city data to easily publish both historic and data streams in the platform, as well as their associated metadata. Rationale: This sub-goal is maintained by the services and functions to accept the publication of city data from data providers (of both open and proprietary data) and prepare the contents for storage and management within the urban platform. Functions include receiving data, performing quality assurance on data, verifying data formatting and document standards, associating meta- data information, and coordinating updates to databases and resources management. Achieve [City data is exploited to its full effect] Goal co-ena bles How we achieve the platform overall goal? Maintain [City data is provided in a harmonised manner] S ub-Goal 1 What actions can maintain the sub-goal? Achieve [Register Publisher] Achieve [Publish City Data] Achieve [Manage Resources] UC1 UC2 UC3 Figure 5. Sub-Goal 1 “City data is collected in an intelligent manner” refinement. Drivers: Ensure data is published in an easy and uniform way. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 16 Actions: For Sub-Goal 1 to be maintained in the long-run it requires the efficient realisation of use cases: “Publish City Data” and “Manage Resources”, as shown in Figure 5. 2.3.1 Use Case: Register Publisher ID: UC1 Refines: SUB-GOAL 1: City data is collected in an intelligent manner Pre-condition: Data Publisher is not logged in the system Actors: Data Publishers Rationale: Data Publishers can register in the platform and request approval to submit city data. They provide valid registration details (to be defined) and wait for registration confirmation. Platform Providers may authorise or not data publishers to offer both open and proprietary city data in the platform. Data submission agreement is a formal agreement between the Data Provider and the Urban Platform defining the terms of the content, standards, metadata creation, and license agreement. The Urban Platform will proactively work with Data Providers to agree on the content, quality and format of city data. Agreements between Platform and Data Providers may be renegotiated on a periodic or ad-hoc basis. Refines into requirements: FREQ.1 to FREQ.5. 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 publisher registration information (e.g. username, password, organisation) 4. The user enters in their information. UC1. Register 5. Platform verifies information and creates account. Publisher o If non-valid information, platform shows error message and returns to step 1. 6. Platform provider is requested to approve the account o Platform acknowledges registration has been successful o If non approved, platform shows error message and returns to step 1. 7. End of registration 2.3.2 Use Case: Publish City Data ID: UC2 Refines: SUB-GOAL 1 - City data is collected in an intelligent manner Pre-condition: User is authenticated in the platform Actors: City data publisher Rationale: The Publish City Data function provides the appropriate mechanisms to receive city data from authorized data providers. Data may be manually uploaded or submitted via APIs. In general, data providers with whom the Urban Platform negotiates submission agreements are the providers of proprietary city data (those producing published material, i.e. publishers) and open data, and they can be either humans or machines. The providers of the Urban Platform will provide data providers with specifications on the content, quality and format of data, and publication terms and conditions. Requirements Specification for Urban Platforms (EIP_SCC Initiative) Page 17 The Publish City Data function may represent a legal transfer of custody for the data in the urban platform, and may require that special access controls be placed on the contents. This function provides a confirmation of receipt of data publication to the Producer, which may include a request to resubmit data in the case of errors resulting from the submission. Once data has arrived, it must undergo several reviews, including virus checking, format compliance, metadata minimum requirement agreement, quality and anticipated content and data formatting. The platform must include the ability to record all actions and decisions made concerning the publication of city data. The reasons for publication failure (e.g. missing metadata information, non-valid dataset) will be provided back to the city data publisher. In some cases, the provider can then resubmit corrected data and metadata information, while in other instances data publication refusal criteria should prevent the publisher from submitting the same dataset at a later time period (e.g. in cases of suspicious datasets – copyrights violation, viruses). When data is successfully submitted (either via APIs or manual upload), it will be processed/prepared for storage into the platform’s database. Specialised Use Cases: The Use Case Publish City Data data is distinguished into two specialised Use Cases: “User publishes city data via data API’s (UC2.1)” and “User manually uploads datasets (UC2.2)”. Subordinated Use Cases: “Store City Data (UC4)” Refines into requirements: FREQ 6 to FREQ.26. Specialised Use Cases Basic Stimulus and Responses 1. Platform provides user with an interface for static data publication 2. User selects datasets to be uploaded 3. User provides metadata associated with the data (license, provenance, ownership, semantics) in accordance with defined standards UC2.1. User manually 4. User requests data publication uploads datasets 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. 7. End of data publication 1. Platform provides user with an interface for real-time data publication 2. User input data API information 3. User provides metadata associated with the data (license, provenance, ownership, semantics) in accordance with defined standards UC2.2. User publishes 4. User confirm information and request data publication 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