When a supplier is generating an IVES message, it may be useful to
coordinate this message with other elements of information such as
earlier messages that have been sent or non-IVES data sources that
are contributing to the message. IVES currently only supports a single
globally shared attribute, namely the Venue ID (VID - ![[*]](crossref.png)
).
If we want to uniquely identify any other element of information then
it is necessary to do so from the perspective of the Supplier that
is doing the identification. Each Supplier can be thought of as having
their own namespace within which they are entirely free to generate
ids for elements. These ids are contained in an optional attribute
named supplierSpecificId.
If a Supplier is utilising the supplierSpecificId then it should be safe for the Consumer to assume that any given (Supplier, Element, supplierSpecificId) combination refers to the same thing. It is not safe to assume that two supplierSpecificIds from different Suppliers refer to the same thing regardless of whether they are applied to the same Element or not because it may be entirely by chance that the two Suppliers are using the same id format and values and it does not mean that they are using this to represent the same conceptual data.
If a Consumer does receive an element of data that does match (Supplier, Element, supplierSpecificId) with an already stored element of data then they should overwrite the existing data with the new data. If the Supplier does not provide consistent supplierSpecificIds then it can be very difficult for Consumers to automatically reconcile updates of information with the information that is supposed to be updated without involving human judgement in the process.
If distinct Suppliers really do want to both represent the same conceptual data in a way that the two (or more) sources can be reconciled then there are a number of options.
)
)
)
)
)
)
)
)
)
)
)