[Data-modeling] Changes to disambiguating properties on CVTs

[Jeff Prucher]

In conjunction with some client changes, we'd like to change (slightly) the
behavior of properties on compound value types. Properties on CVTs can have
one of three states: disambiguator, not a disambiguator, and hidden. In the
current client, the "not a disambiguator" properties can only be seen in
table views, and are particularly hard to edit through the client.

The proposal is to change the client's default behavior with CVT properties.
All properties on a CVT would be displayed on the topics that expect the
CVT, unless they are marked as hidden (that is to say, all non-hidden
properties will behave the way disambiguating properties currently do).
Disambiguators would take on a slightly different semantics, and would be
used to identify which are the primary or most important properties on the
CVT. For example, on the Education CVT, the most important properties are
Student and Institution, for Film Performance it would probably be Actor,
Film, and Character. This only affects CVTs; no change would be made to the
way properties are handled on standard and enumerated types.

These changes will help us to build better display logic into the client.
We'll have greater ability to highlight key properties in the client through
interface cues and more intelligent property ordering on key templates such
as the topic and view page.

The change to client code will only really affect CVTs with
non-disambiguating properties that should instead be hidden. We'd hope to
clean these up in the commons types before the code change. Users are
encouraged to review their own CVT types and flag any non-disambiguating
properties that they do not want to display as hidden. The later step would
be to review existing CVTs and identify the primary properties. We hope to
make these changes along with next week's client release on Tuesday (June
9). 


Jeff Prucher
Type Librarian & Ontologist
Metaweb Technologies, Inc.