From dc9bc2bcbe66784dde1ed4a3e51114d69e9052fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9sar=20Henrique=20Bernab=C3=A9?= Date: Fri, 2 Aug 2024 10:22:40 +0200 Subject: [PATCH] Minor adjustments --- level_1/metadata.rst | 2 +- level_1/properties/catalog.rst | 6 +++--- level_2/index.rst | 8 ++++---- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/level_1/metadata.rst b/level_1/metadata.rst index 718d674..dd8546c 100644 --- a/level_1/metadata.rst +++ b/level_1/metadata.rst @@ -19,4 +19,4 @@ Figure 5 also depicts what information is mandatory for resources connecting to :alt: Metadata schema for connection to the Rare Diseases Virtual Platform diagram. :width: 100% - Figure 5 Metadata schema for connection to the Rare Diseases Virtual Platform diagram. Source: `link `_ \ No newline at end of file + Figure 5 Metadata schema for connection to the Rare Diseases Virtual Platform diagram. Source: `link `_ \ No newline at end of file diff --git a/level_1/properties/catalog.rst b/level_1/properties/catalog.rst index 41ec09f..f3240fa 100644 --- a/level_1/properties/catalog.rst +++ b/level_1/properties/catalog.rst @@ -29,6 +29,9 @@ Catalogue * - **Theme** - Points to an URL that specifies relevant ontology concepts that classify the catalogue. Typically, these can be looked up using the `Ontology Lookup Service (OLS) `_ or Bioportal. - | dcterms:theme + * - **Keyword** + - Keywords applicable to this patient registry + - | dcterms:keyword * - **Contact Point** - Pointer to a Contact Point, Range is vCard - | dcat:contactPoint @@ -79,9 +82,6 @@ Catalogue * - **ODRL Policy** - An ODRL conformant policy document (`https://www.w3.org/TR/odrl-model/ `_) expressing the rights and/or responsibilities associated with access to and/or use of the resource. This should point to a URL where this conformant document has been published. - | odrl:hasPolicy - * - **Keyword** - - Keywords applicable to this catalogue - - | dcat:keyword * - **Logo** - A link to the graphic representation of this resource. - | foaf:logo diff --git a/level_2/index.rst b/level_2/index.rst index 0d550f4..dca2add 100644 --- a/level_2/index.rst +++ b/level_2/index.rst @@ -6,16 +6,16 @@ Requirements to achieve level 2 Level 2 enables the discovery of resources by remote querying of aggregated descriptive information, and/or a limited amount of anonymous record information. This latter is provided either as safe/obfuscated record level data or (when using the Fair-in-a-Box (FiaB) software) aggregating/counting queries over record-level data. When querying at this level, the response can provide yes/no answers, metadata, or record counts (which can be thresholded or windowed) and will not expose the underlying data. For example, for the query ‘How many patients are defined with a certain Human Phenotype Ontology (HPO) code in the dataset?’, the answer would just be an approximate count of patients. This information can be valuable for researchers to assess whether a resource is likely to have relevant data for their research question based on their respective study design and methodology. This requires that the Level 1 connection is already established. -In Level 2, the focus shifts from merely publishing organisational metadata of a resource to uncovering valuable insights about the resource based on aggregated exploration of its contents, enabling researchers to gauge resource suitability without revealing sensitive data. This is enabled by the Beacon v2 API that was adapted for the EJP RD context. The **EJP RD Beacon v2 API** [`link `_], operates at two levels depending on the resource type: +In Level 2, the focus shifts from merely publishing organisational metadata of a resource to uncovering valuable insights about the resource based on aggregated exploration of its contents, enabling researchers to gauge resource suitability without revealing sensitive data. This is enabled by the Beacon v4 API that was adapted for the EJP RD context. The **EJP RD Beacon v4 API** [`link `_], operates at two levels depending on the resource type: #. **/catalogs endpoint level:** Involves answering queries based on summary metadata about a resource, and this is most suitable for the querying of catalogues (I.e., resources whose content comprises of lists of other resources). #. **/individuals endpoint level:** Entails answering queries based on safe exploration of records within a resource, and this is most suitable for querying of individual registries, biobanks and knowledge bases (i.e., resources with data about entities such as patients, biosamples, cell lines, etc). -To be queryable at this level, the resource must follow the **EJP RD Beacon v2 framework** [`link `_], allowing querying at an aggregated level while preserving data privacy. The data elements queried at this level are based on the Common Data Elements (CDEs) for rare disease registration [`link `_]. +To be queryable at this level, the resource must follow the **EJP RD Beacon v4 framework** [`link `_], allowing querying at an aggregated level while preserving data privacy. The data elements queried at this level are based on the Common Data Elements (CDEs) for rare disease registration [`link `_]. -Beacon v2 itself consists of two components: the Framework and the Models. The Framework contains the format for the requests and responses, whereas the Models define the structure of the data response. In the context of EJP RD VP Level 2 querying, the queried summary metadata (catalog level) and safe data (record level) can be provided in any convenient format, including the EJP RD metadata schema (catalog level) and the CARE-SM (record level). +Beacon v4 itself consists of two components: the Framework and the Models. The Framework contains the format for the requests and responses, whereas the Models define the structure of the data response. In the context of EJP RD VP Level 2 querying, the queried summary metadata (catalog level) and safe data (record level) can be provided in any convenient format, including the EJP RD metadata schema (catalog level) and the CARE-SM (record level). -The overall function of these components is to expose an interface through which users can query a resource. Beacon v2 interfaces have formal, machine-readable definitions that follow the OpenAPI Specification, that defines the capabilities of the API. Content-based discovery queries can be initiated from any query point in the VP network (e.g., the EJP RD VP portal) by a Beacon-based API as long as the resource has exposed its data following the EJP RD Beacon v2 framework with the filters and models described in the EJP RD VP API specification [`link `_]. These filters are briefly described below. +The overall function of these components is to expose an interface through which users can query a resource. Beacon v4 interfaces have formal, machine-readable definitions that follow the OpenAPI Specification, that defines the capabilities of the API. Content-based discovery queries can be initiated from any query point in the VP network (e.g., the EJP RD VP portal) by a Beacon-based API as long as the resource has exposed its data following the EJP RD Beacon v4 framework with the filters and models described in the EJP RD VP API specification [`link `_]. These filters are briefly described below. Level 2 endpoint types: Catalogs and Individuals ------------