Mappings to Wikidata - status

[tombaker]

My notes from 2020 about mappings to Wikidata:

It seems that in Wikidata, "exact match" is preferred, though in SKOS, exact match is transitive: if A is an exact match to B and B is an exact match to C then A and C are exact matches. It didn't seem to us that exact match was fitting for our mappings so we searched for alternate properties.

The possible mapping predicates:

• P2888 Exact Match https://www.wikidata.org/wiki/Property:P2888 . For example, see generic query and Joachim's query for Wikidata properties mapped to Schema.org
• P1709 Equivalent Class https://www.wikidata.org/wiki/Property:P1709 . For example, see Query:WDItems_mapped:DcClass.
• P2235 External Superproperty https://www.wikidata.org/wiki/Property:P2235 .
• P2236 External Subproperty https://www.wikidata.org/wiki/Property:P2236 .

• P1628 Equivalent Property https://www.wikidata.org/wiki/Property:P1628 . See also Query:WDProperties_MappedDCProperty.

  • labels in multiple languages for DC properties, alongside Wikidata equivalents
  • definitions in multiple languages for DC properties, classes, and datatypes, alongside Wikidata equivalents
  • definitions in multiple languages for (in this case just one) /elements/1.1/ property: dc:publisher, alongside Wikidata equivalent
  • definitions for /terms/ properties and classes, alongside Wikidata equivalents

Joachim suggested that mappings be reviewed by Usage Board but Liam Wyatt, a program manager for the Wikimedia Foundation, pointed out that this would formally not be necessary given that the purpose of Wikidata is to allow everyone to help and make changes.

We had some discussion of how Wikidata should be presented, eg, as a query (as listed above) or as a (three- or four-column) static table, such as a list of DC Properties Mapped to Wikidata Properties prepared by Grace Johnson. A query would show the current reality on Wikidata, while a static table would allow for notes and comments and would show what the Usage Board has determined the mappings to be.

If we were to build off of the queries listed above, we might want to make some improvements. For example, the query that lists Wikidata properties mapped to DC properties includes items as well as properties; a filter could be added to correct this mistake.

A table could be hosted on the page Wikidata:Dublin_Core.

More fundamentally, would the mappings live on Wikidata as property values, where the community can edit, or would we put them onto a page where only DCMI could edit?

Note that in July 2020, we decided to prioritize mappings to Schema.org over mappings to Wikidata.

[niklasl]

More fundamentally, would the mappings live on Wikidata as property values, where the community can edit, or would we put them onto a page where only DCMI could edit?

I do believe Wikidata is an active data application with a very living vocabulary, so the mappings to DC should live there. We could of course continue to act as part of the Wikidata community in adding (and maintaining) these mappings there.

However, we could also make a set of proposed sets of "opt-in" mappings, in RDF, published by us. These suggested mappings must of course be in separate RDF documents (graphs), and not part of the default RDF document that DC terms resolve to. We could set up a repository (e.g. dc-mappings) here for that and add some Turtle files with tentative mappings for e.g. Wikidata and Schema.org.

(Eventually, any recommended mappings could be linked to from DC Terms using some kind of vocabulary-link semantically somewhere in between owl:imports and <link rel="alternative stylesheet"> ...)

[tombaker]

One of the takeaways from our two meetings about mappings in July 2020 was the notion that since most properties are more granular than the 15 Dublin Core properties, it would be more appropriate for other vocabularies to make incoming mappings to the broader Dublin Core properties than for DCMI to map out to narrower properties.

If we had a Turtle file of mappings on a repository, as Niklas suggests, we could invite people to make pull requests for additional mappings. In effect, the DC properties could serve as link magnets - as hubs for incoming isSubpropertyOf mappings. (Or might we consider using SKOS mapping properties?)

Of course, there would need to be someone, or a small team of people, keeping an eye on those pull requests, and occasionally opening an issue and asking members of the Usage Board to weigh in. But it would ideally take less work and collective attention span to proceed this way than to pick up the mappings with the more "expensive" option of trying to do this on scheduled teleconferences.