Download Intelligent discovery, configuration and composition of devices in a

Quantifying structural matches
As results are constructed, there is a need to distinguish meaningful from trivial matches.
Trivial in terms of being expressed as superficial elements of a device description satisfying
a request, in preference to more meaningful results. We suggest superficial by virtue of
branch terms being only minimally qualified by the presence of leaf terms in the results.
Additionally, a module has greater qualitative worth where the sub-structure has multiple
branch terms matching at the same level.
Where branch terms correspond but there is minimal quantitative qualification at the
leaf level, we intend to reject the sub-match. Not only would removing these trivial cases
be preferred but also for more subtle problem specific ones, where key quantitative factors
fail to correspond (refer to later process enhancements section). The motivation for a
metric to measure the strength of structural correspondence arises from the importance of
leaf level quantitative matches in generating meaningful results. Particular terms are
critical to describing the purpose of a module and qualifying the dimensions of sought after
form and function.
To determine whether to discard a sub-match as trivial, we use an ad-hoc uncertainty
scheme to guide the search and use problem-specific information to define it. The
requester is permitted to assign a factor as a qualification of certainty, at desired points in a
structural description. Suitability of a sub-match is determined by whether a summation of
its certainties achieves a threshold value. The requester specifies key points where a
summation must reach an acceptance measure in order for the sub-match to be included in
the results.
For example, a request for an audio codec seeking a module that can convert a signal
from analog-to-digital could be expressed as a single task_element module with 2
categories (task & control), each comprising subcategories and aspects with sought after
values. A sample application of weightings and thresholds used during testing appears as
follows:
__________________________________________________
...
[[task_element, [], [], [], [0,14]],
[[task, [], [], [], []],
[[function, [], [], [], [0,9]],
!
[[direction, [], [5]], [uq, us, enum, [analog_to_digital]]],
!
[[sampling_rate, [], [2]], [frequency, hertz, =, [48000]]],
!
[[data_channels, [], [1]], [system, integer, =, [2]]],
!
[[bit_resolution, [], [1]], [system, bit, =, [16]]]],
[[role, [], [], [], []],
!
[[principal, [], [5]], [uq, us, enum, [convert]]]]],
[[control, [], [], [], []],
[[approach, [], [], [], []],
!
[[operate, [], [1]], [uq, us, enum, [required]]]]]]
...
__________________________________________________
At the leaf level, weightings are assigned (single number in the 2nd square brackets), with
greater emphasis placed upon matching the conversion direction and role as converter. At
the branch level, there are additional weightings of zero value (left hand number in 4th set
of square brackets]. However, there are comparisons requested with the certainties
summation [right hand number]. To illustrate the idea of building a sub-match, the lower
function subcategory comparison is obviously a lesser threshold than the higher
task_element module level. Failure of either results in the sub-match being rejected, which
causes a flow on effect of failing to reach a later threshold for acceptance.
116