dc:date vs oio:date_created for new terms

[matentzn]

moved from OBOFoundry/OBOFoundry.github.io#906

[cmungall]

Each such proposal must be accompanied by an implementation plan, plus name of an FTE to implement.

E.g. either

1. Modify owlapi oboToOwl code. Should accept both but normalize to dc:date. Coordinate subsequent releases of owlapi4+5, robot, protege. 1 java dev, 40hrs
2. Provide wrapper within odk that post-processes both obo and owl files. 1 python dev, 80 hrs

[matentzn]

For this particular ticket, I was thinking maybe we can get away without aligning with OBO format for now, and accept that these rows will look a bit ugly in OBO format. The ontologies we checked are all over the place with using dc:date and oio:date_created, and I think we can harmonise without fixing the tools (in this case). We cannot do that in some other cases, like IAO:115 and some such, but I feel like with this one we could..

[cmungall]

See also #52

[cmungall]

Agree with @matentzn

[cmungall]

also need to harmonize on range: string literal or xsd date

[shawntanzk]

Uberon/CL call has given thumbs up for tech team to settle it.

if use dc - announce a date, clean up, and then after implement QC

[zhengj2007]

See #52

If we decide to use dc:date, is it the date that the term created or last updated? Do we need two date APs, one for creation date and one for last updated date.

[matentzn]

I dont think we should not derive an answer to @zhengj2007 question from current practice, but I would like to suggest to use dcterms:date for last updated and dcterms:created for creation date, see https://www.dublincore.org/specifications/dublin-core/dcmi-terms/