The uses cases represent in this chapter are structured, according to their main character, into business use cases and functional use cases. The general idea is that the basic and high level use cases lead to more detailed use cases, the functional use cases and at a last stage the operations.

Federation examples

Use Case A - Search for registry content within the registry federation

This is the overall use case for discovery processes and functions within the registry federation. It assumes that respective content is already registered in the federation. From use case A several more functional use cases are derived (A1, ..).

• #2330
• Status - v2 (merged to include feature catalogue and UML model items)
• Use case form to be copied in when agreed
• Priorisation: High

Use case A-1: Retrieve (the ids of) all known extensions of a given register (item)

• #2435
• Status:
• Priority:

Use case A-2a: Retrieve all register items of a register (item) extension (including the items in the extended register)

• #2436
• Status:
• Priority:

Use case A-2b: Retrieve all register items of an a register (item), including the values in all known extensions

• #2438
• Status:
• Priority:

Use Case B - Register new registry content in the federation

• #2333
• Status - v1 (still to be merged to include feature catalogue and UML model items)
• Use case form to be merged and agreed
• Priorisation: High?

Use case B-1a: Register an asset (registry, register, register item) in the federation

• #2431
• Status:
• Priorisation:

Use case B-1b: Register an extension of an asset (register, register item) in the federation

This use case assumes separate registers for assets and extensions in the federation's register of registers.

• #2432
• Status:
• Priorisation:
•  

Use case B-2a: Register an extension of an asset (register, register item) in the federation

This use case assumes just one register for assets in the federation's register of registers. This register includes information about the extensions.

• #2433
• Status:
• Priorisation:

Use case B-3: Mark items or individual values as used

This case is aiming att flag register items or values as used and to avoid that these items are going to be deleted or changed.

• to be populated

Use Case C - Update register content

Use case C-3: Update the information about a federation asset (registry, register, register item)

• to be populated

Use case C-4: Remove an asset (register, register item) from the federation

• to be populated

Use case V - Validation of data.

• The Use case consists of a validation tool that checks incomming datafiles with environmental monitoring data. The validation tool will operate on both values and codes from different EF-areas. Two national “clones” of the Registry (@JRC) and the Data Dictionary (@EEA) will be used in a M2M-process. At present (2015-05-19) the validation tool is connecting to the central Registry (http://inspire.ec.europa.eu/registry) and a national clone of Data Dictionary (http://dd.eionet.europa.eu/). The main goal is to cut time consuming manual QA-processes and instead, let the “machines” do the basic quality control of EF-data.

Other use cases

Use Case G: Automated propagation/dissemination of registry content updates

• #2331
• Status:
• Priority:

Other operations

• Validation (is something a valid extension? is something a valid code list value? is something a valid register item or code list entry at a particular point in time or during a particular period of time? - such as for (re)validation of data with a reference time frame in the past)
• Translation (local publiucation of translations of labels, definitions, descriptions)
• Retrieve all register items of an extended register (item) that have been modified (changed status) since a given date

Aspects & dimensions to consider

• Versioning
  • Distinguish between modification date and validity date. Example: Add a registry item in June that becomes valid the following January.
• Multi-linguality
• Different types of register connections
• Actors/access rights - which use cases are accessible to which types of users (registering new content, updating register content available only to specific types of users)

Alternate way of describing the use cases

My impression could very well be incorrect, but it seems we are struggling a little bit with describing the use cases, in particular on how to express the goal of the actor and without placing too many assumptions on the actual implementation. The idea proposed here would be to use the user story format from agile software development, which places the emphasis on those aspects. The list below is a try to use this format to capture most of the use cases described above, in some cases on a higher level.

Use cases concerning the registry federation

• RF1 – As a data provider I want to make my registry known in the federation, so that can share my code list extensions for others to re-use.
• RF2 – As a data provider I want to make any changes about my registry known in the federation, so that anyone looking for my code list extensions have the correct information on who has published them and where to find them.
• RF3 – As a data provider I want to make my code list extensions known in the federation, so that they can be used by others.
• RF4 – As a data provider I want to make an update of the status of one of my code list extensions, or value(s) therein, known in the federation, so that anyone using them has the latest version.
• RF5 – As a data provider I want to add a new value to a code list already extended and published in the federation, so that I can use the existing code list extension instead of creating a new largely duplicated extension.
• RF6 – As a data provider I want to make a new translation of one of the code list extensions, or value(s) therein, known in the federation, so that it can used by others.
• RF7 – As a data provider I want to make an updated translation of one of the code list extensions, or value(s) therein, known in the federation, so that it can used by others.
• RF8 – As a data provider I want to make sure that an extension of code list created by someone else is valid before I use it, so that I know my data published is correct according to the specifications.
• RF9 – As a data provider I want to see if there are any suitable extensions already published for a code list, so that I can use them for my published data instead of creating my own extension.
• RF10 – As a data provider I want to get the information needed on a published extension of a code list I have found in the federation, so that I can implement it in my data to be published.
• RF11 – As a data provider I want to see what assets in the federation that has been added or updated, so that I can assess whether I need to update my published data.
• RF12 – As a data provider I want subscribe to information on updates for specific assets in the federation that I am using, so that I can assess whether I need to update my published data.

Comments: As pointed out by Michael L. in #2330 the user can be someone else than a data provider – who are those users and what are their goals? Do we always assume an open license for provided extensions?

Use cases concerning the Inspire registry software

• RS1 – As the central EU registry owner I want to make a new register item known to all possible users, so that they can use it in their data published.
• RS2 – As the central EU registry owner I want to make an update of any of my register items known to all possible users, so that they can update their data published accordingly.
• RS3 – As a data provider I want to download all, or parts of the registry content in the central EU registry, so that I can use it as a local copy in my own registry software for easier access etc.
• RS4 – As a data provider I want to download any updates of the registry content in the central EU registry, so that I have the latest version in my local copy of the registry content.