[Accessforall] Are common terms a flawed concept?
colinbdclark at gmail.com
Fri Dec 20 11:48:59 EST 2013
Thanks for your response. I really appreciate hearing your perspective, and it sounds like we’re getting clearer on the issues here. A few more comments inline.
On Dec 19, 2013, at 6:17 AM, Christophe Strobbe <strobbe at hdm-stuttgart.de> wrote:
> During our face-to-face meeting in Madrid, it was
> even claimed that the SP3 solutions in Cloud4all use only common terms and
> no application-specific terms. (Quoting from the meeting minutes: "Only
> common terms are part of this integration phase"
> Lastly, some of the SP3 implementers provided only a list of existing
> common terms when we asked them which terms they would like to see
> supported in the second pilot phase. This included an organisation that
> integrates an AT with GPII without having access to that AT's source code.
> (This situation was rectified last week.) How likely is it that that AT's
> settings match the common terms and that no application-specific terms are
> It is when I noticed this misunderstanding about implementing common terms
> in SP3 that I started thinking about the potential consequences and wrote
> my original mail.
When people say “uses common terms” or “only common terms are part of this phase,” I think they typically mean “transformations have been written between common terms and the application’s own settings.”
I understand your concern about the ambiguity here, but I don’t think I’d read too much into it. I don’t think it’s an attempt to convince SP3 developers that they need to change their internal formats to common terms. It is, however, great that our implementers are integrating their applications, and since common terms and transformations are a critical piece of infrastructure for integrating with several of our Matchmakers, it’s a good thing that they’re “using common terms."
>> The main motivation for common terms is to serve as a “meeting point” for
>> a diverse community of developers and application vendors. Common terms
>> represent common ground where we can translate to and from
>> application-specific representations.
> This is how I have always understood common terms. There is no
> misunderstanding on my part.
I’m glad we’re on the same page.
> Interoperability is the keyword here. We both agree that implementers
> don't need to implement common terms natively in order to ensure
> interoperability; they can use their application-specific terms and
> provide mappings and transformations to common terms.
> My concern is specifically about common terms where the value range
> consists of enumerated values.
> (a) They would be unattractive to implement natively because that implies
> that you commit to their value range. (Fortunately, you don't need to
> support them natively.)
> (b) They can lead to a loss of precision in setting values when you need
> to convert from an application-specific terms that uses a specific set of
> enumerated values to a common term that uses a different set of enumerated
> values and there is simply no good mapping. (This would be a bit like
> translating colour terms between languages without recourse to RGB or
> something similar.)
> (c) In theory, they can also lead to a loss of precision when an
> application-specific term uses a value range based on continuous data (or
> even simply integers) whereas the common term uses enumerated values. This
> is something we are currently avoiding by our choice of data types and
> value ranges for the common terms.
Loss of precision is a consequence of our “personalized anywhere” model of interoperability in general. A setting for one application may not map directly to the setting of another, and there’s an inevitable lossiness in the translation process. This issue exists for every Matchmaker, regardless of what strategy it uses or whether or not it employs common terms to do its work. Clearly the challenge, and I don’t think it’s an impossible one, is to ensure that common terms are structured suitably to avoid the worst cases of precision loss wherever possible.
The key advantage to common terms and the transformation process is that it’s architecturally transparent. Common terms provide a shared reference point to discuss the relationship of one solution to another. And with declarative transformation rules, we have a visible, parseable, understandable artifact (i.e. a standardized data structure) that represents the exact nature of the loss--the transformation rules document.
It sounds like there are many cases where what we need is good modelling practices for common terms. Enumerations, clearly, can raise problems. I think they’re very useful for capturing needs that are familiar to the user—your high contrast example is a good one—but we also need to ensure that the finer-grained terms are available as well so that we don’t have a major loss of precision. My tendency, when modelling common terms, would be to start with the finer-grained representation first. Perhaps we need to do a better job of that.
I don’t see any reason why we can’t plan for an extensibility model for enumerated common terms to ensure that they’re not limited to developers as well. I’d love your feedback and designs for this if you have any specific ideas on how we can enable this.
More information about the Accessforall