dcmi/usage

Proposed namespace for OpenWEMI

kcoyle opened this issue · 6 comments

kcoyle commented

We suggest this public namespace for OpenWEMI.

URI: http://purl.org/dcx/openwemi/

This is parallel to the namespace that was developed for LRMI. The local IRI can be:

https://www.dublincore.org/dcx/openwemi/(date)

The date will be the latest edit date. We expect the OpenWEMI vocabulary to be stable once it is approved.

niklasl commented

Do you prefer http here over https://purl.org/dcx/openwemi/?

I'd recommend https, to avoid the risk of someone eventually accessing these definitions for the first time on a compromised network, receiving something strange instead... It's hopefully academic, but there are unknown unknowns here.

(And I'd say these gritty technical details are the price we pay for the immensely added value of dereferenceable logical names.)

philbarker commented

https: makes sense. I nearly suggested it in the working group but then I noticed that every other DCMI vocab uses http: (the price we pay for DCMI being almost as old as the web).

HughP commented
kcoyle commented

I honestly don't care. It should be whatever DCMI thinks is best.

kcoyle commented

After discussion, it is clear that the PURL.ORG service is less desirable because DCMI does not have direct control over the service. It is being suggested that DCMI take direct responsibility for its own persistent identifiers going forward, under the dublincore.org domain. The proposed persistent namespace for OpenWEMI is https://ns.dublincore.org/openwemi/.

jneubert commented

Just thoughts from the side line, re.:

Schema.org was http and moved to https. I don't recall the technical details. But there was some engineering to forward things along from http to https. maybe DCMI could do the same for the older vocabularies. - Hugh

I have gone through this with gndo : A point to consider is that every existing sparql query is obsoleted by a changing a namespace uri, even if only the protocol changed. Neither redirects nor owl:sameAs statements (or similar) in the published vocabulary help in case of queries (which are often buried deeply in scripts, and now silently produce empty results). Published 3rd party data would either use the old or the new protocol/base URI, which would add to the mess.

So while the proposed namespace for openwemi in #126 (comment) looks fine, I wouldn't recommend changing namespaces for older vocabularies without pressing need.

  • 👍2