We should fix the dc namespace for good.

[matentzn]

As discussed here we should make it explicit that we standardize on a particular variant of the dc namespace, which makes it easier for downstream tools to merge ontologies. As you can see here, the description property, among others, has two IRIs:

http://purl.org/dc/elements/1.1/
http://purl.org/dc/terms/

For many properties these are synonymous. Due to their wide use, I suggest here to nail the first one (http://purl.org/dc/elements/1.1/) for dc terms, and discourage the use of the second. This makes building tooling easier as well (like ROBOT report).

There is no action item for OMO here; i would just leave this open for reference and encourage people to voice opposing views.

[nataled]

If one was to be selected as the version to converge on, I"d defer to the suggestion by the Dublin Core team that "While the /elements/1.1/ namespace will be supported indefinitely, DCMI gently encourages use of the /terms/ namespace." This, to me, has the advantage of many more description properties while fully covering the content of elements.

For context, see the second bullet point under "The four DCMI namespaces" description within "Section 1: Introduction and Definitions" of this document: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

[graybeal]

They may 'gently' encourage the use of terms, but the people I've talked to in the wider semantic community don't make any bones about it—they think there's no reason to use the elements namespace. (I think because all the elements concepts are in the terms namespace; and because the terms namespace has many more concepts; and because, for a period at least, the semantic management/servicing of the elements was pretty poor. But that last point someone may prove me wrong on, it was several years ago now.) I use the terms namespace exclusively.

[cmungall]

Yes, @nataled and @graybeal are correct, and in fact we discussed this previously
OBOFoundry/OBOFoundry.github.io#540

As you can see, Tom baker, the technical director of DCMI stepped in and advised us to use dcterms

And @nataled fixed the license principle to clarify:

http://www.obofoundry.org/principles/fp-001-open.html

I think we should aggressively eliminate the use of dce, including robot report giving errors.

[matentzn]

This is great, thank you all for the clarification :)

[jamesaoverton]

Note that the OBO registry itself uses a mixture: https://github.com/OBOFoundry/OBOFoundry.github.io/blob/master/registry/ontologies.ttl#L3