Open jeswr opened 5 months ago
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?
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 .
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.
Notes for implementation:
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
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
- In
marco_term_table
which generates the HTML for terms in specs...
s/marco_term_table/macro_term_table/
, I think?
The range of
dc:contributor
isdc:Agent
so I would expect the result of executing the query to be a set of triples whose objects are the URIs of the authorsInstead the result is