Altinn/altinn-resource-registry

Map resource attributes to understand how to use them

Closed this issue · 2 comments

Description

Analyse the list of attributes to understand how functionality needs to be built to support required standards, limitations and how they will show up in other products in Altinn or externally.

In scope

No response

Out of scope

No response

Additional Information

No response

Analysis

Tasks

Conclusion

No response

@sorensensig I think we have achieved the overall objectives here. At the moment we have two maps from design that go beyond the first delivery:

For the standalone registering a resource in Studio (sub-tab should says 'section on page'):
Screenshot 2023-05-22 at 09 19 30

For the in-app process of registering a resource in Studio:
Screenshot 2023-05-22 at 09 19 43

For all fields:

  • Identifier: pointer
  • Title: freetext
  • Description: freetext
  • hasCompetentAuthority: ! questions remaining
  • ownedBy: set by the company profile
  • contactPoint: e-mail, phone and document that may be taken from the company profile
  • homepage: URL to the service homepage
  • thematicArea: LOS or EUROVOC - this groups the services
  • type: main activity - this is only for public services and describes the function of services, currently lacks the vocabulary to describe non-public services
  • sector: data theme - whom the service is meant for, question is næringskoder (NACE) used for the same purpose?
  • keyword: freetext - should this use begrepskatalog?
  • status: select - of the resource using SKOS
  • spatial: multi-select - many suggestions but NUTS or Geonames
  • produces: multi-select - what is the outcome of the resource/service i.e. pdf, event - lists can be ...
  • validFrom: dates - feedback is that there is no plan for versioning, a new app is created instead
  • validTo: dates - see above
  • rightsDescription: longer freetext description that then gives the user informed consent about proceeding
  • publicService: boolean? - ! is this taken from the user profile or set by service owner?
  • isLimitedToSpecificUsers: change to isLimitedToSpecificReportee i.e. specific organisation, only offered to the police or police officers. Makes this multi-select?
  • availableFor: does this overlap with sector?
  • selfIdentifiedUsersEnabled: boolean? - existing functionality
  • reference: code, external ID and referencing i.e. Altinn 2 and Altinn 3 identifiers
  • enterpriseUserEnabled: boolean? - virksomhettsertifikat connected to org number
  • eventTypes: can be anything in the future depending on what service owners choose to emit, but life events and business life events will be covered soon by CPSV
  • resourceType: to be determined
  • isPartOf
  • hasPart

There is significant crossover with Altinn Studio apps as seen in the above diagram and discussions about what fields should be pre-filled from existing information in the app and what will least disrupt the user flow (developer in studio).

Our conversations with Felles Datakatalog (FDK), Team Portal and Brønnøysundregistrene have to date indicated that we need to keep in mind different needs:

  1. Where data is shown: FDK need as much metadata as possible filled out in order to have meaning in the catalog. They are interested in this solution as it means that they can utilise it themselves in the future. FDK is an endpoint of our product and this needs to be articulated or perhaps even have consent from service owners
  2. Similarly, many service resources will end up shown on Norge.no and the portals so it is vital that the correct information is there for end users. It was flagged as a major pain point at the moment that fields such as owner of a service, the type of service or thematic area and spatial are not consistently shown in the catalogue for citizens making it difficult to find your local kindergarten for example. Metadata quality and quantity matters here.
  3. Developers are often handed the information about policy from other stakeholders in their organisation - they are happy to code this Studio apps but they are not the stakeholder responsible for checking this from a legal or ethical standpoint. This role was attributed to lawyers in one conversation and it should be considered how we can better support lawyers in these standalone tools for policy.
  4. The major user of resource registry has been flagged as IT professionals but not necessarily programmers - these are service owners that are responsible in organisations from an IT perspective who are often experienced in these areas and not juniors. We need to better understand and test with these end users as well as 3 as both share responsibility for the outcomes and settings of resources.