Dxwg: Review new DCTERMS version to check possible conflicts with DCAT2

[andrea-perego]

See http://lists.w3.org/Archives/Public/public-dxwg-wg/2020Jan/0107.html

A new version of DCTERMS has been published on 20 Jan 2020 (also as an ISO standard), which should be reviewed to verify possible conflicts on how DCTERMS are used in DCAT2:

https://www.dublincore.org/news/2020/01-16-dcmi-metadata-terms-revised/

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/

[dr-shorthair]

Interestingly, all the URIs are http:, not https:

There was discussion on Twitter today criticising schema.org for keeping their http: URIs alive. @danbri points out that it folds back to https: (I think) and also that disabling http: is contemplated for some future date. However, this kind of server knitting is beyond my expertise.

[nicholascar]

The Australian Government Linked Data WG will likely switch from HTTP to HTTPS for all PID URIs within a couple of months.

[andrea-perego]

On a slightly different note, it seems the fragment identifiers of the different sections of DCTERMS have been changed.

E.g., the URL for dct:publisher used to be

http://dublincore.org/documents/dcmi-terms/#terms-publisher

Also http://purl.org/dc/terms/publisher used to redirect to that URL, if I am not mistaken. But now it points to

https://dublincore.org/specifications/dublin-core/dcmi-terms/#publisher

In both cases, as you can see by clicking either of the above URLs, you land at the beginning of the page, and not at the relevant section.

The reason is that the current working URL is

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/publisher

Of course, not an issue by itself, but this change is affecting all the links to specific terms of DCTERMS in bib references of all specs having them, DCAT included.

BTW, there's the same problem with terms in DCMIType and DCAM. E.g.:

http://purl.org/dc/dcmitype/Service

http://dublincore.org/documents/dcmi-terms/#dcmitype-Service

http://purl.org/dc/dcam/domainIncludes

http://dublincore.org/documents/dcmi-terms/#dcam-domainIncludes

Besides restoring the original URLS, an alternative fix would be to implement an additional redirect from

http://dublincore.org/documents/dcmi-terms/#terms-publisher

and

http://purl.org/dc/terms/publisher

to

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/publisher

etc.

@kcoyle , @tombaker do you think it would make sense to report this issue and see if there is a possibility to have it fixed?

[makxdekkers]

The Australian Government Linked Data WG will likely switch from HTTP to HTTPS for all PID URIs within a couple of months.

As far as I am concerned, 'switching' from HTTP to HTTPS for PIDs really means you're minting new URIs and breaking the persistence of these HTTP URIs. You could of course make the statement, as I have seem some people do: "HTTP and HTTPS URIs are equivalent". That may be the case but identifier http://somedomain/something is different (for character-by-character compare) from https://somedomain/something. So if you are comparing identifiers, you will need a piece of software that says "_if the strings are not the same but the fifth character is an 's' and the rest is the same, treat them as the same_", or maybe even "_compare the strings after '//'_", or have statements like
http://somedomain/something owl:sameAs https://somedomain/something.
So what if a new protocol comes along, and it is decided that HTTPS was not such good idea after all, are users of the PIDs going to be forced to change their compare routines again and again? Where's the persistence in that?

[makxdekkers]

On a slightly different note, it seems the fragment identifiers of the different sections of DCTERMS have been changed.

E.g., the URL for dct:publisher used to be

http://dublincore.org/documents/dcmi-terms/#terms-publisher

Also http://purl.org/dc/terms/publisher used to redirect to that URL, if I am not mistaken. But now it points to

https://dublincore.org/specifications/dublin-core/dcmi-terms/#publisher

@andrea-perego. If you are asking the owner of persistent URIs to also commit to persistence of the URLs behind the persistent URIs, aren't you asking for too much?
As I see it, a persistent URI plus content negotiation guarantees that you can always get to the right URL behind the URI and the maintainer can rearrange what sits behind the URI as needed.

[andrea-perego]

@makxdekkers said:

@andrea-perego. If you are asking the owner of persistent URIs to also commit to persistence of the URLs behind the persistent URIs, aren't you asking for too much?
As I see it, a persistent URI plus content negotiation guarantees that you can always get to the right URL behind the URI and the maintainer can rearrange what sits behind the URI as needed.

Sorry, probably I was not clear. What I'm asking is whether it would be possible to fix the redirection to the new working URLs.

Coming back to my examples, the following PURL

http://purl.org/dc/terms/publisher

redirects to

https://dublincore.org/specifications/dublin-core/dcmi-terms/#publisher

whereas, with the new DCTERMS fragment IDs, it should redirect to

https://www.dublincore.org/specifications/dublin-core/dcmi-terms/#http://purl.org/dc/terms/publisher

About URLs like

http://dublincore.org/documents/dcmi-terms/#terms-publisher

it is true they were not supposed to be persistent, but they have been around for a while. Implementing a redirection from them to the new URLs would be desirable - and could be done very easily via a RewriteRule.

[tombaker]

About URLs like

http://dublincore.org/documents/dcmi-terms/#terms-publisher

it is true they were not supposed to be persistent, but they have been around for a while. Implementing a redirection from them to the new URLs would be desirable - and could be done very easily via a RewriteRule.

@andrea-perego Thank you for bringing this our attention. We will look into it and report back.

[tombaker]

@andrea-perego I have discussed this with @paulwalk. We agree with @makxdekkers that "a persistent URI plus content negotiation guarantees that you can always get to the right URL behind the URI and the maintainer can rearrange what sits behind the URI as needed". Indeed, we changed the anchors when we redesigned the DCMI Metadata Terms document in the context of a migration to a static site generator.

Currently, the URI http://purl.org/dc/terms/publisher resolves to the top of a Web page that has an Index of Terms with links to anchors for individual properties within that page. We feel this is "good enough", as mapping from the old document anchors to the new would take some development effort, those mappings would need to be maintained, and the mappings could make future document redesigns more complicated. Can you live with our position?

[andrea-perego]

Many thanks for considering my feedback, @tombaker & @paulwalk.

I still think the current solution is non-optimal, but of course I can live with it ;)

[andrea-perego]

As far as I was able to see, the changes done in the current version of DCTERMS have no particular impact on DCAT.

For our records, I include below the changelog available at

• Release: 2020-01-20 (Current Version)
  • Definitions of properties and classes in the /terms/ namespace follow ISO 15836-2:2019 as announced in January 2020, with minor differences of house style.
  • Usage comments for Language and Date in the /elements/1.1/ namespace updated as per corresponding properties in the /terms/ namespace
  • Two new properties added: dcam:domainIncludes and dcam:rangeIncludes.
  • rdfs:range changed to dcam:rangeIncludes for: dct:accessRights, dct:accrualMethod, dct:accrualPeriodicity, dct:accrualPolicy, dct:audience, dct:conformsTo, dct:contributor, dct:coverage, dct:creator, dct:educationLevel, dct:extent, dct:format, dct:instructionalMethod, dct:language, dct:license, dct:mediator, dct:medium, dct:provenance, dct:publisher, dct:rights, dct:rightsHolder, dct:spatial, and dct:temporal.
  • rdfs:domain changed to dcam:domainIncludes for: dct:medium.
  • Clarifications of wording for definitions and usage comments.
  • Additional usage examples.
  • Erratum 2020-03-11: Fixed reference URL for dcterms:ISO3166.

Unless there are any issues to be reported, I would propose to close this issue.

[riccardoAlbertoni]

Unless there are any issues to be reported, I would propose to close this issue.

+1 from me

[andrea-perego]

Closing issue.