We have been using the wrong dublin core URI to indicate license all this time

[cmungall]

Is it just me that finds dublin core kind of confusing for such a small and basic ontology?

According to http://dublincore.org/documents/dces/

There are two URI prefixes

• dce - http://purl.org/dc/elements/1.1/
• dcterms - http://purl.org/dc/terms/

The latter duplicates the 15 terms of the former in order to add RDF constraints. So we have dce:contributor and dcterms:contributor; and we also have dce:rights and dcterms:rights.

When should we use dce vs dcterms? The former has the blessing of IETF/ISO/NISO, but the latter has a more complete RDF formalization. So which to choose? I admit I just copy and paste what others have done. An additional complication is that they have no OWL commitment which is a potential train wreck waiting to happen (e.g. when we combine conflicting commitments to AP vs OP vs DP).

OK but a bigger issues seems to be that there is no dce:license, yet this is what we use in the vast majority of our ontologies!

there is a dcterms:license, but it's not in the core set: https://en.wikipedia.org/wiki/Dublin_Core#DCMI_Metadata_Terms

see also
http://www.dublincore.org/documents/dcmi-terms/#terms-license

You can see the distribution of our usage here:

http://sparql.hegroup.org/sparql?default-graph-uri=&query=prefix+dce%3A+%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Felements%2F1.1%2F%3E%0D%0Aprefix+dcterms%3A+%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0D%0A%0D%0ASELECT+DISTINCT+%3Font+%3Fp+WHERE+%7B%0D%0A+%7B+%3Font+dce%3Alicense+%3Flicense+.+BIND+%28%22dce%3Alicense%22+as+%3Fp%29+%7D%0D%0A+UNION%0D%0A+%7B+%3Font+dcterms%3Alicense+%3Flicense+.+BIND+%28%22dcterms%3Alicense%22+as+%3Fp%29+%7D%0D%0A+UNION%0D%0A+%7B+%3Font+dce%3Arights+%3Flicense+.+BIND+%28%22dce%3Arights%22+as+%3Fp%29+%7D%0D%0A+UNION%0D%0A+%7B+%3Font+dcterms%3Arights+%3Flicense+.+BIND+%28%22dcterms%3Arights%22+as+%3Fp%29+%7D%0D%0A%7D&format=text%2Fhtml&timeout=0&debug=on

The ones at the top are wrong AFAICT

Of course many ontologies still don't embed their license in the header - this is being taken care of in another ticket.

Either dce:rights or dcterms:rights are valid, and within the norms of the wider semantic web, although OBO intends to signal we require license not rights.

These are our docs:

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

The OWL recommendation is ambiguous, as the dc prefix is not defined, but this is typically a builtin for dce.

Action: change docs to unambiguously state dcterms:license, and chase down and harmonize all ontologies.

Question: what does it say that this problem has been unnoticed for so long...?

[cmungall]

This is the SPARQL

prefix dce: <http://purl.org/dc/elements/1.1/>
prefix dcterms: <http://purl.org/dc/terms/>

SELECT DISTINCT ?ont ?p WHERE {
 { ?ont dce:license ?license . BIND ("dce:license" as ?p) }
 UNION
 { ?ont dcterms:license ?license . BIND ("dcterms:license" as ?p) }
 UNION
 { ?ont dce:rights ?license . BIND ("dce:rights" as ?p) }
 UNION
 { ?ont dcterms:rights ?license . BIND ("dcterms:rights" as ?p) }
}

[balhoff]

This continually annoys me. I lean towards using dcterms everywhere, since it includes everything from dc. OWL API has dc "elements" built in though: https://github.com/owlcs/owlapi/blob/51863e86d9aaa0e30d30529b00022edb0b4aa677/api/src/main/java/org/semanticweb/owlapi/vocab/DublinCoreVocabulary.java

[jonquet]

In our MTSR 2017 paper about MOD1.2 we have done a semi automatic review about the use of metadata properties over 222 ontologies and this is our comment on this point:
http://www.lirmm.fr/~jonquet/publications/documents/Article_MTSR-2017_MOD1.2.pdf

"
(4) there is a confusion between the use of DC and DCT as the latter includes and refine the 15 primary properties from the former
"

Some developers prefer to refer DC (more) and some prefer DC Terms for the similar element. In the context of semantic web applications, although using DC is not incorrect (as an annotation property), DCMI recommends using DCT that provides domain and range information for properties:
http://acva2010.cs.drexel.edu/omeka/items/show/10210

Si indeed, I would recommend in the header of an ontology to use DC Terms.
This is also the choice we have made in MOD1.2:
https://github.com/sifrproject/MOD-Ontology

[nataled]

The documentation http://www.obofoundry.org/principles/fp-001-open.html has been updated to the correct prefix and purl where necessary.

[tombaker]

Is it just me that finds dublin core kind of confusing for such a small and
basic ontology?

This is a fair point. Some of the confusing aspects -- the idiosyncratic terminology (e.g., elements = properties), the parallel core properties with and without ranges... -- are more understandable if one considers that Dublin Core predated RDF.

When should we use dce vs dcterms? The former has the blessing of
IETF/ISO/NISO, but the latter has a more complete RDF formalization. So
which to choose? 

Dublin Core was published as an RDF vocabulary before OWL appeared and before domains and ranges became widely used. Many /elements/1.1/ properties had been used in the wild with both literals and objects, so we could not just assign ranges without invalidating data, hence the creation of fifteen /terms/ counterparts to the core properties.

FWIW, DCMI has "gently encouraged" use of /terms/ over /elements/1.1/. Alas, incorrect use of literals and objects is for many data aggregators a fact of life.

Note that the RDFa Core Initial Context used dc and dcterms for /terms/ and dc11 for /elements/1.1/ (though dce is also widely used).

DCMI has been working with ISO on drafting an ISO 15836 Part 2, which will extend the ISO standard to /terms/ properties and classes. The ISO committee tasked with reviewing the draft has proposed some revisions, so we have re-activated the DCMI Usage Board (maintenance committee) to decide on those changes and to address a few other long-standing issue. I posted a low-key announcement on a public list several weeks ago. We will make a high-profile announcement in the coming weeks, with a larger committee, and expect to start work in May.

An additional complication is that they have no OWL commitment which is a
potential train wreck waiting to happen (e.g. when we combine conflicting
commitments to AP vs OP vs DP).

If you feel it would help for DCMI to make an OWL commitment, please formulate a proposal (paragraph or two, plus footnotes and a rationale in plain language for public consumption) and we can put it on the agenda!

Question: what does it say that this problem has been unnoticed for so long...?

If this group has any other comments or proposals, please get in touch! We may use the Github issue tracker, as you do, though this will be for the committee to decide. In the meantime, please just drop me a line.

[cmungall]

Thanks for your input @tombaker @jonquet @balhoff

Yes, it seems clear we should use dcterms, thanks for updating the docs @nataled thanks for updating obi @proccaserra

I'll leave this open til we have worked through all ontologies and followed up

@tombaker - I will think about a proposal for owl commitment, maybe @alanruttenberg will want to help with that

[cmungall]

Some fixes from @balhoff

geneontology/go-ontology#18208
obophenotype/uberon#1532

[nlharris]

Are there still aspects of this that need to be addressed? If so, is there anyone other than @cmungall who could work on them?

[balhoff]

chase down and harmonize all ontologies.

This specific issue is being addressed by the OBO dashboard.

change docs to unambiguously state dcterms:license

Not sure if this has been done.

[balhoff]

Actually I see @nataled has updated the docs. I think this can be closed (I don't have permission).