next up previous contents index
Next: 1.5.2 supplierDefinitionId Up: 1.5 Shared Attributes Previous: 1.5 Shared Attributes   Contents   Index

1.5.1 supplierSpecificId

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 - [*]). 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.

  1. The Suppliers can group together to form a single amalgamating Supplier which privately merges the data, does any offline reconciliation and de-duplication and then sends out all the data as a new single Supplier. As the data is now all coming from a single Supplier, it is possible to safely make assertions that identical (Element, supplierSpecificId) combinations do refer to the same conceptual data.
  2. The distinct Suppliers can agree on a shared <Property> type that will represent their shared id format. For example, if you have a consortium of Suppliers named Acme then they may all agree to include elements such as:

    <Property type=''Acme.sharedId.Event''>ev-1234</Property>
    Providing that the Supplier that they are all sending their data to is aware of the purpose of the Acme.sharedId.Event property type then the Supplier can use this to facilitate the merging of the data streams from the different Suppliers. Please note that the format of both the Property type and the Property value is entirely arbitrary and not enforced in any way.

The supplierSpecificId attribute is found on the following elements:

next up previous contents index
Next: 1.5.2 supplierDefinitionId Up: 1.5 Shared Attributes Previous: 1.5 Shared Attributes   Contents   Index
Alex Fiennes 2010-04-13