---+++ Versioning of LSIDs

   1.  There is no particular reason to use the LSID version element to identify a new version rather than issuing a completely new LSID.  From the standpoint of the specification and of software tools, these two approaches both lead to completely new LSIDs which are unrelated to any earlier LSID.
   1.  The LSID specification requires us to use a new LSID whenever the data are changed, but we are free to choose how to handle changes in metadata.
   1.  Depending on the organisation of their databases, some providers will be able to offer different versions of their data under different LSIDs, while others will not be able to track changes in metadata.
   1.  Many users of standard reference data (e.g. scientific names from IPNI) will wish to have an identifier which they can use to refer to the name, and always to link to the most recent version of the name record, regardless of changes in the database, e.g. to fix spelling mistakes.
   1.  TDWG working groups should therefore consider the application of LSIDs to their data types to develop specific recommendations on any metadata elements which should never be changed without issuing a new LSID.
   1.  TDWG should develop (or better, adopt) RDF metadata propoerties which can be included in any TDWG metadata object to indicate the following:
      * The LSID to be used to retrieve current (meta-)data for the object (to be used when the current LSID refers to an old version of the (meta-)data)
      * The LSID to be used to retrieve (meta-)data for an object which has replaced the current object (e.g. in cases where the current LSID is now deprecated as it referred to an object now recognised to be a duplicate of another object, potentially with its own version history)
      * A date/time of last modification for the metadata
      * That the current LSID has "volatile" metadata (particularly when a date/time for modification cannot be supplied, i.e. when the data provider has no history for the data and may return a new version at any time, meaning that users should always allow for the possibility that the metadata may have changed)