Uploaded image for project: 'SAFe Program'
  1. SAFe Program
  2. SP-3500

Metadata Management Integration - Metadata Access API

Change Owns to Parent OfsSet start and due date...
    XporterXMLWordPrintable

Details

    • SRCnet
    • Hide

      BH: Once defined this API, libraries can discover data from the data lake

      Show
      BH: Once defined this API, libraries can discover data from the data lake
    • Hide

      AC: A combined documented and implementable API

      Show
      AC: A combined documented and implementable API
    • Team_SRCPT
    • Hide

      Integration of TAP with Rucio at:

      https://gitlab.com/ska-telescope/src/src-mm/ska-src-mm-rucio-ivoa-integrations

      Demos provided on using DACHs TAP server and service discovery

      Show
      Integration of TAP with Rucio at: https://gitlab.com/ska-telescope/src/src-mm/ska-src-mm-rucio-ivoa-integrations Demos provided on using DACHs TAP server and service discovery
    • 24.2
    • Stories Completed, Integrated, Outcomes Reviewed, Satisfies Acceptance Criteria, Accepted by FO
    • PI24 - UNCOVERED

    • PI19-PB

    Description

      This feature is the first to be defined to declare, implement and integrate metadata access methods

      • Definition of API required to access metadata related to data

      This feature should define the interface signature and methods (e.g. Discover Data using science metadata, the discovery of data using data identifiers, the discovery of running services, etc)

      • Discovery of data using science metadata could be done by making use of protocols like ObsCore/TAP
      • The discovery of data should have information on how to access referenced data using data identifiers and could have several methods (e.g. using different data link elements). For example, one to get a stream to the data  (e.g. HTTP, HTTPS or a cloud interface), another to obtain the location of the data, another to stage data locally from a remote location, etc

      For every method, it has to be identified input and output parameters, protocols, workflow (description of the process at the server side to evaluate sync or async), error handling (error codes and description), etc. This documentation should be enough to implement a server fulfilling it and a client that connects to it.

      Main work could be done in different features  (there are already some features that are doing partial parts of this feature) but documentation of the different interfaces should be combined in a single location.

      Attachments

        Issue Links

          Structure

            Activity

              People

                r.bolton Bolton, Rosie
                Jesus.Salgado Salgado, Jesus
                Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Feature Progress

                  Story Point Burn-up: (100.00%)

                  Feature Estimate: 0.0

                  IssuesStory Points
                  To Do00.0
                  In Progress   00.0
                  Complete24.0
                  Total24.0

                  Dates

                    Created:
                    Updated:
                    Resolved:

                    Structure Helper Panel