This issue is related to the workaround described in FAIRDataTeam/FAIRDataPoint#798.
HealthDCAT-AP (R5 at the time of writing) defines a list of controlled vocabularies they require to be used. To help the user enter the correct values, autocomplete fields are a great solution.
The problem we've encountered is adding autocomplete sources in the settings for sources that share a RDF Type, but have a different endpoint or query. Concrete example:
With the current settings, we're able to add one source. Adding a second source for the same type (haven't tried it yet, but I assume it won't work) is not an option. From the form perspective, having a sh:class skos:Concept and a dash:editor dash:AutocompleteEditor for both properties without an option to discern the source will result in users adding values from the wrong controlled vocabulary.
The proposed solution would be to (optionally) allow for more specific targeting the settings fields for defining autocomplete sources. In the scenario described above having the option to define the class and/or the property would solve the issue.
This issue is related to the workaround described in FAIRDataTeam/FAIRDataPoint#798.
HealthDCAT-AP (R5 at the time of writing) defines a list of controlled vocabularies they require to be used. To help the user enter the correct values, autocomplete fields are a great solution.
The problem we've encountered is adding autocomplete sources in the settings for sources that share a RDF Type, but have a different endpoint or query. Concrete example:
adms:status) should have a value of typeskos:Conceptand should come from the EU Vocabularies Distribution Status controlled vocabulary.dcat:theme) should have a value of typeskos:Conceptand should come from the Dataset Theme Vocabulary controlled vocabulary.With the current settings, we're able to add one source. Adding a second source for the same type (haven't tried it yet, but I assume it won't work) is not an option. From the form perspective, having a
sh:class skos:Conceptand adash:editor dash:AutocompleteEditorfor both properties without an option to discern the source will result in users adding values from the wrong controlled vocabulary.The proposed solution would be to (optionally) allow for more specific targeting the settings fields for defining autocomplete sources. In the scenario described above having the option to define the class and/or the property would solve the issue.