OGC AP Records schema for processes and applications

[pzaborowski]

Based on the D5.1 list of properties, we shall propose a general OGC Records schema.

In this CWL example, the additional information is defined along with metadata using the Schema.org (s:) tags. Below, will explore the importance of various Schema.org tags when describing tools: ● name: used to provide a clear and concise title for the tool. It acts as the primary identifier for the tool and helps users quickly understand its purpose. ● description: allows for a more detailed explanation of the tool's functionality and objectives. It provides users with essential context and insights into the tool's capabilities and potential use cases. ● keywords: includes relevant terms and phrases that describe the tool's main functionalities, scientific domain, and other important aspects. These keywords aid in searching and categorising tools, making them easier to find. ● softwareVersion: specifies the version of the tool, aiding in accurate reproduction and tracking changes over time. ● programmingLanguage (optional): specifies the programming language used on the tool. This information helps users assess the compatibility and requirements of the tool with their computational environment. ● sourceOrganization: is used to indicate the organisation(s) responsible for creating or maintaining the tool. It helps establish the origin and credibility of the tool. Subtag Organization describes the organisation's details, including: ○ name: the name of the organisation ○ url: the organisation's website ● author: identifies the primary creator of the tool. It provides attribution and contact information for the tool's creator. Subtag Person contains details about the individual, including: ○ name: the author's name ○ email: the author's email address ● contributor (optional): lists individuals who have contributed to the development or maintenance of the tools. It acknowledges their efforts and contribution to the project. Subtags Person contains details about each contributor, including: ○ name: the contributor's name ○ email: the contributor's email address ● maintainer (optional): lists an individual or organization that manages contributions for the specific version of the development. Subtags Person contains details about the maintainer: ○ name: the contributor's name ○ email: the contributor's email address ● codeRepository: includes the URL of the version control repository where the CWL file is hosted. This link allows users to access the tool's source code, enabling collaboration, contributions, and version tracking. ● dateCreated: specifies the date when the tool was initially created. This information helps users understand the tool's age and potential evolution over time. ● license (optional): includes the URL to the application package licence. ● citation (optional): citation or reference to another document. ● temporalCoverage (optional): indicates the period that the content applies. Should be defined by a textual string indicating a time period in ISO 8601 time interval format. ● spatialCoverage (optional): indicates the area or place(s) which are the focus of the content. By incorporating these Schema.org metadata tags in tools, developers and researchers can effectively document and communicate essential details about their tools. This standardised approach to metadata usage promotes better integration, discoverability, and reusability of tools in scientific and computational communities.

Queryables are defined https://github.com/ILIAD-ocean-twin/data_access_api/blob/main/metadata/services_applications.md

[pzaborowski]

publisher can be the author, needs to be checked with DCAT conventions

[pzaborowski]

Here are GeoDCAT-AP and Records Core properties respectively:

● name: used to provide a clear and concise title for the tool. It acts as the primary identifier for the tool and helps users quickly understand its purpose.

dct:title - title

● description: allows for a more detailed explanation of the tool's functionality and objectives. It provides users with essential context and insights into the tool's capabilities and potential use cases.

dct:description - description

● keywords: includes relevant terms and phrases that describe the tool's main functionalities, scientific domain, and other important aspects. These keywords aid in searching and categorising tools, making them easier to find.

dataset dcat:keyword - keywords but mind ISO and DCAT has 'themes' also which shall be referable. would it make sense to support these as well?

● softwareVersion: specifies the version of the tool, aiding in accurate reproduction and tracking changes over time. >

not known - not known

● programmingLanguage (optional): specifies the programming language used on the tool. This information helps users assess the compatibility and requirements of the tool with their computational environment.

not known - not known

● sourceOrganization: is used to indicate the organisation(s) responsible for creating or maintaining the tool. It helps establish the origin and credibility of the tool. Subtag Organization describes the organisation's details, including: ○ name: the name of the organisation ○ url: the organisation's website

may be geodcat:resourceProvider or geodcat:originator or geodcat:distributor - not known if this role is responsible for "maintaining" what is the relation to the 'maintainer'?

● author: identifies the primary creator of the tool. It provides attribution and contact information for the tool's creator. Subtag Person contains details about the individual, including: ○ name: the author's name ○ email: the author's email address

dct:creator - contacts

● contributor (optional): lists individuals who have contributed to the development or maintenance of the tools. It acknowledges their efforts and contribution to the project. Subtags Person contains details about each contributor, including: ○ name: the contributor's name ○ email: the contributor's email address

maybe contactPoint? - contacts

● maintainer (optional): lists an individual or organization that manages contributions for the specific version of the development. Subtags Person contains details about the maintainer: ○ name: the contributor's name ○ email: the contributor's email address

contacts

● codeRepository: includes the URL of the version control repository where the CWL file is hosted. This link allows users to access the tool's source code, enabling collaboration, contributions, and version tracking.

that shall be 'link' with new type potentially

● dateCreated: specifies the date when the tool was initially created. This information helps users understand the tool's age and potential evolution over time.

dct:created - created

dct and records supports also updated, what you do after an update?

● license (optional): includes the URL to the application package licence.

dct:license - license + range eventually

● citation (optional): citation or reference to another document.

not known - link if a reference

● temporalCoverage (optional): indicates the period that the content applies. Should be defined by a textual string indicating a time period in ISO 8601 time interval format.

dct:spatial - time

● spatialCoverage (optional): indicates the area or place(s) which are the focus of the content. By incorporating these Schema.org metadata tags in tools, developers and researchers can effectively document and communicate essential details about their tools. This standardised approach to metadata usage promotes better integration, discoverability, and reusability of tools in scientific and computational communities.

dct:temporal - geometry

Please take a look on the: https://semiceu.github.io/GeoDCAT-AP/drafts/latest/#overview-of-bindings-for-geodcat-ap-core

https://docs.ogc.org/DRAFTS/20-004.html#record-model

To check if there are any other potentially useful properties to be added. Potentialy: type (also to distinguish from data assets), update date and themes could be helpful IMO. It may be good to propose Building Block for the service record based on selected properties. it can be one with schema.org and the other with dcat/records/OIM. we're working on the dcat based properties. mapping the scheme could be part of the OIM, but need to confirm that mapping first.

[pzaborowski]

programmingLanguage has a glossary in IEEE, maybe in others as well like redhat or apache, we shall use it or create our own

[pzaborowski]

There is one new resource that could be helpful. We want to have similar one for the STAC and STAC profile for the applications from this issue: https://ogcincubator.github.io/geodcat-ogcapi-records/bblock/ogc.geo.geodcat.dcat-records/json-ld