Investigate option to add support for codelists including various usage patterns on properties using them

[jakubklimek]

See this DCAT-AP 3.0.1 draft section, basically:

1. The property MUST use as range values codes from {codelist}
2. The property MUST have at least one value from {codelist}
3. The property IS RECOMMENDED to use as range values codes from {codelist}
4. The property MAY use as range values codes from {codelist}

[rob-metalinkage]

Is there "tooling" available for CSV to create the sort of summary table at https://semiceu.github.io/DCAT-AP/releases/3.0.1-draft/#expected-usage-of-controlled-vocabularies

From exploring various approaches to binding schemas and vocabularies it is clear that this sort of reporting is a basic need. Commonality of expression will be helpful.

Understanding where the binding comes from is also very valuable - for at least three cases:

• nested profiles
• mix-in (additive) profiles
• "complex" schemas (real applications such as metadata in general, survey, built environment, descriptions of environmental observations)

(note these patterns are often used in combination)

here is an example: https://icsm-au.github.io/3d-csdm/docs/wa-profile/#https://linked.data.gov.au/def/csdm/surveyfeatures/OccupationMark

this was driven by an (semi) ad-hoc solution to this mapping:

a CSV

https://github.com/icsm-au/3d-csdm-profile-wa/blob/main/profiles/wa-vocab-bindings.csv

uplifted to an RDF graph vis JSON-LD - using the QB vocabulary

https://github.com/icsm-au/3d-csdm-profile-wa/blob/main/profiles/wa-vocab-bindings.ttl

  parcel:purpose a qb:CodedProperty ;
    qb:codeList vocabs:wa-parcel-purpose,
        vocabs:wa-secondary-parcel-purpose ;
    rdfs:range termtype:ParcelPurpose ;
    sh:targetClass surv:Parcel .

Why not persist with just this approach?: A: because it is not easily transported to a JSON-native application, where the same meta-model of binding structural model elements to vocabularies is equally important.