Documenting parameters in taxonomy

[ryanmwhitephd]

Parameters can represent various types of information and how the taxonomy documents that information is not clear at this time. For example, Parameters may refer to Unit under test (UUT) inputs, UUT input quantities, influence quantities that need to be a measured independent of the UUT (environmental conditions), parameter values taken as constants (assumed constant values rather than measured parameters).

• Influence parameter can be described by its aspect or kind of quantity alone (e.g. Temperature)
• Influence parameter needs to be qualified (e.g. Temperature.Ambient)
• Influence parameter is described by another measurand (e.g. Measure.Temperature.Ambient)
• ....

This is kind of a blocker, see issue #44.
Let's brainstorm possible types of parameters and decide how to document and what to reference.

[MarkKuster]

I think we should control this in the schema or UIs to the extent effective. In general, parameters should refer to another taxon for the least ambiguity. We should discuss whether in those cases it should include the Measure-Source token or not. Another case: property values. Given that we want to limit the values to controlled lists (e.g., thermocouple types) we should control the parameter name also, e.g. ThermocoupleType. So maybe all parameter names conform either to another taxon or an entry from a separate controlled list. Perhaps we even change the schema to recognize two parameter types, e.g., quantities and nominal properties.

[SchwartzMichael]

The names will be controlled in the Taxon definition in the XML file.

And we can expand the schema to include references/links to other related elements like MLayer, quantity kind, ISO, SI units, etc.

Including a cross-reference guide in the taxon definition will increase the user value of a taxon.

[ryanmwhitephd]

@colinindy, what about frequency? Can you describe this in relation to a measurand definition?

[SchwartzMichael]

I started using UUT. in Metrology.NET to it was a parameter that applied to the UUT only.
In Metrology.NET, the reference standards and the UUT come together, making the test ready for automation.
An example would be the word "Range" a range parameter would be ambiguous (UUT range or Reference Standard Range).
By adding UUT.Range separates it from the reference standard range, keeping range out of any parameter that is passed to the uncertainty calculators and/or SoA calculators.

This was extended to UUT.Input to denote automatic connection messages for the Automation Software.

Keep in mind I'm looking at this from the DCR point of view. I want to digitally define the test requirements for a device I'm sending to a calibration lab. I want to define it in such detail that the calibration tech doesn't need a pre-written manual to perform the calibration. So my use case is a little different.

Note: None of the Metrology.NET optional parameter extensions are needed in the standard configuration.
This is the power of this format; any user of the taxonomy can add an optional parameter to further define the data.

[SchwartzMichael]

I think we should keep the parameter names short and focused around the Taxon's needs.

We can also include data about the parameter in the taxon definition like the ID of the M-Layer definition and/or information about another taxon.

This additional data should be in the Taxon Definition, and NOT part of the package data moved from system to system.

We need to update the Taxon Schema to support the M-Layer, Quantity Kind, and Referenced Taxons for the parameters.