Dxwg: DCAT files import wrong Dublin Core URL

[bdonohue29]

The DCAT file published here tries to import Dublin Core Terms (dct:) from the following URL: http://purl.org/dc/terms/

But it looks like Dublin Core updated their URLs, so this import statement can't resolve. For example, in desktop Protege, it simply fails to import Dublin Core. In Web Protege, it blocks any import of DCAT.

In my local copy, I updated the imports statement to point to a more current URL for Dublin Core Terms, and it worked fine: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl

Note: This would just be a change to the owl:imports statement, not to the dct: namespace.

[dr-shorthair]

I just tested http://purl.org/dc/terms/ and got good RDF representations of Dublin Core when using the HTTP header "Accept: application/rdf+xml" and "Accept: text/turtle". In fact the latter is identical to what you get from https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl . SO looks like Protege is choking on something other than just getting the correct RDF graph. IMAO the shorter URI (which corresponds to the dcterms namespace) is a better target for import.

However, it is true that the optimum object of <owl:imports> is poorly understood and weakly specified. While it can be useful in showing all the members of a dependency in an IDE, it is not necessary to import a namespace in order to mention elements from it in another graph. Perhaps it would be better to remove all imports from the official release, and then let users load dependencies using the facilities provided in their tools, when and if they need to.

[andrea-perego]

@dr-shorthair said:

[...] Perhaps it would be better to remove all imports from the official release, and then let users load dependencies using the facilities provided in their tools, when and if they need to.

+1 from me.

[tombaker]

Someone else has written to DCMI with the same problem, also with Protege, but I find that our server is correctly serving RDF/XML when this is requested (as @dr-shorthair also found).

If there is anything we can do to make it easier for Protege users, please let me know.

[bdonohue29]

Gotcha, understood this is on the Protege side, which in my experience tends to have lots of issues with importing.

[tombaker]

@bdonohue29 , all - If anyone here can suggest a sentence or two of explanation, I will look for a way to add it to the DCMI terms documentation.

[bdonohue29]

Sure

When loading DCAT into Protege (v5.x.x), either from the Web URL http://www.w3.org/ns/dcat# or from a downloaded local copy, Protege will fail to import the Dublin Core Terms vocabulary. (See screenshot below.)

One workaround is to download a local copy of DCAT and update the relevant owl:imports statement to point to https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl. Then, Dublin Core Terms will import correctly in Protege.

[tombaker]

@bdonohue29 I have wrestled this down under the 280-character limit for a tweet:

Some users of Protégé (v5.x.x) report problems importing http://purl.org/dc/terms/. Workaround: update owl:imports to point to the dublincore.org address that appears when you click on the PURL.

I propose to tweet this, along with your screenshot, then add a reference to the tweet somewhere in the DCMI terms documentation.

Do you all like this approach, and do you all approve the text above?

[bdonohue29]

@tombaker Looks good, except I haven't tested pointing the import to the dublincore.org url you get when it redirects from the purl.

Rather, I had to point to a .ttl file hosted on dublincore.org, namely: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl

(Which is almost the same, but includes the "www" prefix and swaps out the "/#" for the ttl file name)

Understood you can't fit that in a tweet. Maybe the following with the second screenshot below? However you want to do it

"Workaround: update owl:imports to point to a ttl file hosted on dublincore.org."

[tombaker]

@bdonohue29 Can you confirm that this is an issue with Protege and not with how we have configured the PURL and the DCMI website?

[bdonohue29]

@tombaker I mean, not with certainty. @dr-shorthair says it's working when requested over http. And apparently other Protege users are running into this issue, so sounds like it's on the Protege side

[tombaker]

@bdonohue29 @dr-shorthair Thus tweeted: https://twitter.com/DublinCore/status/1369219886598262784 .

[kcoyle]

I don't think that a tweet has reliable longevity. It seems to me that the area of the introduction (in the DC terms document) where the namespaces are documented is the place to do this. First, to explain that the purl.org namespaces resolve to the HTML page. Then that access to the RDF/ttl (? is there an RDF/XML version?) via HTTP can be achieved by adding "Accept: application/rdf+xml" and "Accept: text/turtle". In situations where that is not viable (e.g. when importing the vocabulary), one should reference the RDF/ttl directly: https://www.dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl

[tombaker]

@kcoyle - @paulwalk and I agree that it would be helpful to add a short section to the introduction to DCMI Metadata Terms about RDF representations, with links to specs about content negotiation and direct links to the Turtle files. I have put this on my list of things to do.

[andrea-perego]

Unless there are any further actions to be taken, I propose we close this issue.

[andrea-perego]

Thanks, @kcoyle . Closing this issue.