...
- In general, I [Patrick] would argue that a taxon is defined by rank as well as name, publication, etc. There are both species and genus taxa for "bufo", for "buteo", etc., so the rank is distinctive, IMO. This simplifies at least one part of the model.
Where do we configure the association of a given vocabulary to a given schema (and UI form) field?
There has been some discussion recently about how and where to configure the information that XSD cannot reasonable express. However, we will need to make a decision (at least for the near term) for how to bind to a vocabulary namespace as the legal range for a given schema field.
- How do we refer to a vocabulary in config files (I [Patrick] think we need some namespace equivalent).
- In what config file do we specify previously-configured vocabularies to load into the system?
- In what config file do we link from a schema field to one or more vocabularies?
By the same token, we need to let the UI know about that association, so that appropriate UI mechanisms (and App tools?) are available.
- In what config file do we link from a UI Form field to the vocabulary(ies) for the associated schema field, or is this automatic in some manner from the App layer?
Finally, we probably need to make clear the class or quality of the vocabulary namespace so the UI can pick the appropriate tools. E.g.,
- If the vocabulary is flat (as for a simple enumeration), then a drop-down list is a likely UI mechanism.
- If the vocabulary is tree-shaped (as for a taxonomy), then some sort of path-aware type-ahead picker is likely.
- If the vocabulary is a faceted ontology, then some variant on the picker may be needed.
- If the vocabulary is a graph (e.g., a taxonomy with relations and/or additional context links), then more UI may be required.
- If multiple vocabularies are allowed, then some blend will likely be required.
- Whether the vocabulary is closed (no new terms allowed), versus open (users can add new terms) will determine associated UI features.