Contributors should reference Agents, not a string literal list of authors about dpv HOT 5 OPEN

True, and this is not a major issue - it would just be cleaner to go with the suggested class and describe as much data as possible in RDF rather than putting it into a string literal.

For reference it is dcam:rangeIncludes which is described as follows.

dcam:rangeIncludes
    dcterms:issued "2020-01-20"^^<http://www.w3.org/2001/XMLSchema#date> ;
    a rdf:Property ;
    rdfs:comment "A suggested class for values of this property."@en ;
    rdfs:isDefinedBy <http://purl.org/dc/dcam/> ;
    rdfs:label "Range Includes"@en .

from dpv.

3. In marco_term_table which generates the HTML for terms in specs...

s/marco_term_table/macro_term_table/, I think?

from dpv.

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/terms/contributor/ says it is 'range includes' dct:Agent instead of just 'range', so we can use other objects/literals here?

from dpv.

Thanks. This requires lots of changes to the work flow we have. All doable I think. So I've put it as to do for the next release.

from dpv.

Notes for implementation:

1. The contributor strings are what is recorded in the spreadsheet. They are a comma separated set of names
2. In vocab_func script to generate the RDF, split the string on comma as a separator and for each name, create an instance of dct:Agent with the name as its dct:title, and add these triples as dct:contributor
3. In marco_term_table which generates the HTML for terms in specs, for contributors retrieve the 'list' (use ensure_list) and select dct_title for each. Same for the ReSpec metadata in each template. Better to create a function (jinja filter) called retrieve_contributors which takes a term and returns a list of strings representing names of contributors
4. Ensure that the new instances are not being list as being part of the vocabulary e.g. in external concepts

from dpv.