implement Controlled Vocabularies

[allyn]

As of CIM v1.4 the CVs used by the CIM are hard-coded into the schemas. CVs should, instead, be stored separate from the CIM at dedicated servers. They should be able to be downloaded as needed by CIM tools and paired with the schemas for validation.

[allyn]

This ticket is being documented here wiki:tickets/778

[allyn]

The restructuring of the CVs in the CIM retains the use of the "open" tagged_value. Is this appropriate? According to Rupert, it is the responsibility of the CV itself - and not the description of the CV in the CONCIM - to know whether it is extensible or not. I have made this change as of r2043.

But I'm not sure if this is the right approach or not.

[rupert]

Hi Allyn,

I'm not sure that you need to remove the open attribute (as you have done), in fact it might be useful to know so we can check locally (rather than having to go to the vocabulary server) that people have not tried to extend a closed vocabulary.

People who write CIM documents should know this information locally as they create the document so it is no bad thing to make them acknowledge it. The questionnaire certainly knows when the information is part of an existing vocab or when it is a user defined extension.

The problem I had was that the attribute value was fixed to true for the particular class in question, so it could not be set to true for one vocabulary and false for another. Simply providing it as a boolean option would work for me - especially as that is what I now output in from the questionnaire :-).

[allyn]

Rupert,

The issue is that I was using the tagged_value of open used in the CONCIM to tell me whether or not a CV was extensible. If it was then the CV element was mixed and value of the "open" attribute of the "controlledVocabulary" sub-element was "true." Otherwise the element was not mixed and the "open" attribute's value was "false."

If you think that things are open when they shouldn't be, then that means that the tagged_value needs to be changed in the CONCIM.

I think there are three possible solutions:

1) Keep the "open" tagged_values in the CONCIM up-to-date. This has a "generating exactly the right XSD" appeal about it, but since the CVs are going to be governed outside the CIM there is a real danger (as you've discovered) of having the wrong information in the CIM.

2) Just don't include any information about being open/closed. This is the current state of the CIM. The CV validation code that I am writing will be able to tell whether things ought to be open or closed.

3) Re-introduce the "open" attribute but don't bind it to an explicit true/false value in the APPCIM. This is what you've suggested in this email. It is then up to the people/tools writing CIM instances to get this right. This sounds promising, but what happens if the CIM says something's open and the CV says it's not?

[allyn]

I have implemented option number 2 above. This closes this issue, and finalises the structure of CVs within the CIM. This ticket cannot be closed, however, until the code to integrate external CVs with the CIM Schemas for validation is complete.

[allyn]

There was an email discussion a while ago started by Rupert about how SKOS may be insufficient to encode the relationships in our CVs.

I thought that we could just "overload" the broader/narrower relations that SKOS already have, but after a lengthy conversation with Rupert I no longer believe that. We talked about using SKOS + some other stuff, using RDF, or using the bespoke XML that the mindmaps already get translated to. These are all valid options - although they all mean that using BODC's server becomes difficult.

Was there a decision made as to the format of the CVs and where they are stored?

Once we know that information, I will be able to complete my CV checker.