Copying (slightly paraphrased) arguments from Slack:
Miika Alonen
The issue is due to content negotiation, as our tool only loads vocabularies from the namespace ... based on the expectation that linked data vocabularies should be published in a way that the machine readable version is resolvable from the namespace. It is the only way to be sure that the vocabulary is the same as expected. You don't want the situation where someone could claim that something is in the vocabulary when it actually isnt. It is the only working mechanism of trust (so far) in the linked data world. (edited)
Vocabularies shouldn't be published with a namespace that cannot be configured. There are many alternative ways to deal with these issues, for example using w3id.org namespace to redirect to any format.
Namespace for the vocabulary is the permanent identifier for the vocabulary, which should be resolvable as a best practice using context negotiation.
Its just expected way to mediate the machine readable vocabulary
And if that mechanism isnt working there is no machine accessable way to determine if something like unece:AccountingAccount is a real thing or not
Nis
I believe we have to revisit this and get creative on a solution. What type of web server are we deploying to? Is there any way it can be configured without needing to deploying a custom application? If not, what sort of applications are supported?
Copying (slightly paraphrased) arguments from Slack:
Miika Alonen The issue is due to content negotiation, as our tool only loads vocabularies from the namespace ... based on the expectation that linked data vocabularies should be published in a way that the machine readable version is resolvable from the namespace. It is the only way to be sure that the vocabulary is the same as expected. You don't want the situation where someone could claim that something is in the vocabulary when it actually isnt. It is the only working mechanism of trust (so far) in the linked data world. (edited) Vocabularies shouldn't be published with a namespace that cannot be configured. There are many alternative ways to deal with these issues, for example using w3id.org namespace to redirect to any format. Namespace for the vocabulary is the permanent identifier for the vocabulary, which should be resolvable as a best practice using context negotiation. Its just expected way to mediate the machine readable vocabulary And if that mechanism isnt working there is no machine accessable way to determine if something like unece:AccountingAccount is a real thing or not
Nis I believe we have to revisit this and get creative on a solution. What type of web server are we deploying to? Is there any way it can be configured without needing to deploying a custom application? If not, what sort of applications are supported?