Page Comparison

Questions

...

• 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.

How will we model and implement the services that support vocabulary functionality?

We can define the basic schemas around a vocabulary item, and around the relations among items (e.g, parent-child). However, we want to have both a Vocabulary service that supports generic vocabularies (like Subject or Concept vocabularies, enumerations, etc.), as well as more specialized services like Location, Person, Organization, etc. that have additional semantics:

• Additional methods that provide specific semantics (e.g., "get closest location given a lat-long pair").
• Extensions to the VocabularyItem to model additional information (e.g., lat-long, altitude or height, origin, taxonomic rank, etc.).

One approach to the modeling is to consider the specialized services as sub-classes or extensions of the Vocabulary service. They can then implement all the Vocabulary methods, and then pass them through to a superclass in the implementation.

Another similar approach is to model the vocabulary schema and methods like an interface definition. We would then have a service that is a base implementation for the simple cases, and then all the variants would support the interface methods and schema as part of their definition (and we can work out the implementation details on the back end).

A related issue is the management of namespaces in the vocabularies. We will need to validate a vocab reference, and so need some sort of registry that can map the pattern of a URI to a vocabulary and so to a handler that validates the actual reference. If we have to have such a registry with handlers, then we might consider having all vocabulary functionality go through a central proxy that dispatches to the different implementations. This basically inverts the interface model. This might be somewhat simpler for clients, but it introduces additional issues:

• If we ask for info about a vocabulary item from a proxy, what is the contract-schema for this call? Is it just the basic vocabulary item information, or does it include the extended schema?
  • If the former, then the client has to make a different call to get the additional information.
  • If the latter, then the contract is effectively variable, which is kind of funky.

• If we instead make the calls on the individual services, how do we model the notion of a handler service in our REST/SOA world, so that a client can get the handler for a VocabularyItem reference and then operate on it?

Should vocabularies define not just allowed relations, but also required relations?

For cases like life-science taxonomy, we may want to preclude orphan VocabularyItems, and so require parent or child linkage. Perhaps this is something that the individual services should implement as part of the their semantics, rather than trying to generalize this. For now, we will not rty to mode this generally, and we can see if some common themes emerge from experience.