Added additional descriptive fields to ResourceConfig

[jesper-friis]

Description

Added more descriptive fields to ResourceConfig to better support data documentation and improving findability and reusability of resources documented with OTEAPI.

Also added examples and more specific documentation of expected values (range) of the fields.

According to dcat should mediaType be an IRI, not just the final part that OTEAPI expects. Added a clarifying note about that.

Unfortunately could description not be added due to name conflict with the description field in GenericConfig. See issue #426.

Type of change:

• Bug fix.
• New feature.
• Documentation update.

Checklist for the reviewer:

This checklist should be used as a help for the reviewer.

• Is the change limited to one issue?
• Does this PR close the issue?
• Is the code easy to read and understand?
• Do all new feature have an accompanying new test?
• Has the documentation been updated as necessary?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.14%. Comparing base (9f7fb05) to head (0feef5a).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #427   +/-   ##
=======================================
  Coverage   83.14%   83.14%           
=======================================
  Files          14       14           
  Lines         617      617           
=======================================
  Hits          513      513           
  Misses        104      104           

Flag	Coverage Δ
linux	83.14% <ø> (ø)
linux-strategies	83.14% <ø> (ø)
windows	82.49% <ø> (ø)
windows-strategies	82.49% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[CasperWA]

What is the reasoning and argumentation for choosing the specific additional attributes that you have? They seem to come from different classes in DCAT.

The examples should be listed through the Field's examples parameter (a list of examples), for more information, see the pydantic docs.

There are some unnecessary syntax changes in existing description values that should be reverted.

The division of the description according to the table definition in DCAT is unnecessary and ill-advised. Instead referring to the definition given by DCAT would be enough, along with the existing verbatim copy of the overall description of each attribute.

Range has no meaning as no context or explanation is given anywhere.

Usage refers to the DCAT usage, not the OTEAPI usage, which may or may not differ.

Reference can be done more elegantly and machine-readable, see #434.

[jesper-friis]

What is the reasoning and argumentation for choosing the specific additional attributes that you have? They seem to come from different classes in DCAT.

As stated in the description of the PR is OTEAPI about data documentation and ResourceConfig about cataloguing. For that we need additional descriptive fields to make the data findable.

The examples should be listed through the Field's examples parameter (a list of examples), for more information, see the pydantic docs.

done

The division of the description according to the table definition in DCAT is unnecessary and ill-advised. Instead referring to the definition given by DCAT would be enough, along with the existing verbatim copy of the overall description of each attribute.

Range has no meaning as no context or explanation is given anywhere.

The range i.e. a semantic description of the type of provided is very useful information. This is not just copy/paste from the DCAT table, but translated to OTEAPI.

Usage refers to the DCAT usage, not the OTEAPI usage, which may or may not differ.

It should not differ. If partial pipelines serialised as RDF with these DCAT properties should be interpreted correctly by others, we must ahead to the standard. If OTEAPI does not follows the DCAT usage, it will be considered as a broken and nonconforming system.