Hello Elliot, Hello everybody, I have made the very same experience. Have you been able to confirm the limitations of the Controlled Vocabulary Support? And how did you work around it?
I have tried a zillion different combinations and this is what has come out: First of all, in dsapce.cfg the comment reads as follows: > ## The DSpaceControlledVocabulary plugin is automatically configured > ## with every *.xml file in [dspace]/config/controlled-vocabularies, > ## and creates a plugin instance for each, using base filename as the name. > ## eg: nsi, srsc. This implies that you dont need to uncomment anything below to make it happen. However, the property > plugin.selfnamed.org.dspace.content.authority.ChoiceAuthority seems not to be handled consistently with other properties in dspace.cfg and seems not to have any default value. I started with these two lines uncommented: > plugin.selfnamed.org.dspace.content.authority.ChoiceAuthority = \ > org.dspace.content.authority.DSpaceControlledVocabulary And I saw the empty list as you described in the Submission process. When commenting out again, I saw a onebox style entry form in XMLUI and twobox in JSPUI. This ment to me that my initial setting with allright. Next, the feature does not seem to be documented in the current 1.7.x user documentation. I have probably read the same page in the development area as a sole source of information for allowed values for optional and required properties: > <https://wiki.duraspace.org/display/DSPACE/Authority+Control+of+Metadata+Values> On this page under > Selecting Choice Presentation Style in the lower half of the page, three valid values are mentioned and explained for > choices.presentation: select, suggest and lookup. There is a table at the middle of the page preceeded by the headline > Relationship with Interactive Submission Configuration In this table, all three values are mentioned as supported for entry field types onebox, twobox und textarea. I tried all three of them. First I tried by modifying directly in my working testinstance, only restarting tomcat. Though I saw some changes, I was not happy with the result. I also tried rebuilding completely but the results were the same. As such it seems that testing modifications to dspace.cfg and input-forms.xml in a working instance, only restarting tomcat is sufficient for this purpose. "Select" showed the empty list as you mentioned in either XMLUI and JSPUI. It was completely impossible to enter anything, which means that you cant come over this step in submission in case the Dublin Core field is required in your repository. "Lookup" opened a popup window. On top, there was a list with one item "not localized" selected. Maybe, Localization is supported in for vocabularies although not mentioned? I did not try out with something like srsc_de.xml. In the lower half of the window, no possible values were shown, even if the search term had the correct spelling of one unique entry in the vocabulary. The search term is to be seen in a entry box and can be modified within the popup window. Below the text entry box, there are three buttons, one of them labeled "Find more…" but it does not reveal any more results. Lookup seems to be just as useless as Select as a choice for choices.presentation.dc.qualifier, even if you enter a search term. Last option "suggest" started to show a long list of possible values as soon as starting to enter text in the box. However, it was not possible to choose from this list. I tried with Firefox 7.0.1 and Safari 5.1 Mac. One had to typ until there was only one suggestion left. Even then, only the part entered manually was inserted when hitting the Add button. Currently, it seems to be the only working option, though not overly helpful in keeping field values consistent. Stop, hold on. When keeping away from the mouse or trackpad completely, there is a way to enter a suggested value as follows: Use the arrow keys to navigate in the list of values offered. The whole value is entered in the field then. However dont use the mouse to click the Add button. The field will be reduced to the part you typed. Instead, hit the Tab key to move on to the Add button. Now, you can use either the Enter key or the mouse to activate the Add button while keeping the whole value. Now for the three optional vocabulary.plugin properties > hierarchy.store, hierarchy.suggest and delimiter. I was not sure as to what the delimiter was ment for. Parsing the controlled vocabulary itself? It did not seem so as the default perl delimiter could not be found in the sample vocabularies srsc and nsi. Maybe, for inserting multiple values in one database field and splitting them up again while reading? When I saw the list shown with setting suggest, I decided that this has only impact on appearance. The delimiter is used to separate levels in a tree structure: "first level term::second level::actual leaf value". Im not sure though as of whether there are other effects of the delimiter besides that. At least it does not seem to be a hinderance when leaving this value unset during experiments. The hierarchy.suggest made me paricularly curious. However I could not find any effect, turning this boolean to true or false while having choices.presentation set to suggest. I was not able to test every possible combination, but I set both hierarchy.store and hierarchy.suggest explicitly to false and tried all three possible values for choices.presentation with no visible effect. I also could not find any information about these two values throughout DSpace Docs, not even in the Developer Doc mentioned above. We have a controlled vocabulary made by ourselves. Everything reported here for the example vocabulary srsc works absolutely the same with our custom vocabulary. So these are the only settings of limited use at least, that I came up with: Uncomment all three of the following lines in dspace.cfg or at least first and last line for controlled vocabularies to work: #plugin.selfnamed.org.dspace.content.authority.ChoiceAuthority = \ # org.dspace.content.authority.DCInputAuthority, \ # org.dspace.content.authority.DSpaceControlledVocabulary Add exactly two lines for each Dublin Core field to be supported by your vocabulary: choices.plugin.dc.whatever = yourvocabulary choices.presentation.dc.whatever = suggest Add a field in input-forms.xml. There are few limitations. The vocabulary tag is obviously required. input-type should be onebox in case of XMLUI, as twobox does not get displayed and only textarea is the only other value supported. Namely dropdown is not supported. I did not try out textarea; onebox is a good starting-point at least. <field> <dc-schema>dc</dc-schema> <dc-element>whatever</dc-element> <dc-qualifier>whatever, optional</dc-qualifier> <label>Your label here</label> <input-type>onebox</input-type> <!-- At least with XMLUI, other values dont make much sense --> <repeatable>set true or false as you like</repeatable> <hint>Give a hint if you want to</hint> <required>Add the required line if you seem fit</required> <vocabulary>yourvocabulary</vocabulary> </field> I hope, somebody will take advantage of my findings. If anybody knows better, please tell! Bye, Christian ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech
