Technical Blueprint version 10

səhifə	7/8
tarix	24.06.2016
ölçüsü	0.54 Mb.

1 2 3 4 5 6 7 8

3.19PHOTO TYPE

3.19.1Definition

Photo type specifies the type of a photo.

3.19.2Relationships

One photo type may apply to several photo references.

3.19.3Contents

The precise contents of the PHOTO_TYPE code list is still to be decided and its specification will be included in a coming release of this document..

4.Code list distribution

This section will discuss policy matters and IT aspects of the Linnaeus code list distribution.

4.1Distribution policy

With regards to the Linnaeus distribution policy, the following principles apply.

4.1.1Responsibilities

The contents of Linnaeus code lists is maintained by the involved code list agencies. These organisations are responsible for the correctness, completeness and the mutual consistency of the data.
The code lists will be distributed by FlorEcom, who will not be responsible for the code lists’ contents. It will only provide the technical platform and protocols to obtain the code lists. This implies that FlorEcom won’t perform any intrinsic processing on the data. In practice, the distribution agent’s job will limited to:

system management and problem solving by distributing the code lists
ensuring the availability of the distribution platform
registering users and distributing login-ID’s and passwords (if applicable)
providing support and technical information about the code lists.

4.1.2Complete set

A basic tenet of the Linnaeus code lists distribution is that any business partner, at any time, must be able to obtain the complete set of Linnaeus code lists from the distribution agent, including possibly expired codes which make up a reference to historical data.
The starting point for the distribution of code lists is that it should be possible at any time for every partner in the chain to obtain the complete set of Linnaeus code lists, along with any future codes and any blocked codes that refer to historic data, as a cohesive unit from the distribution system. This set of data, to which the technical blueprint applies, concerns the set starting with the letter F, i.e., the F files.
In addition to the F files, C files will be delivered. The C files will contain a selection taken from the F files (“C” standing for “current” and “F” standing for “full”). The C files will contain the product codes, with related items, for which the deadline has not yet been reached and for which the effective date is previous to or the same as the day after tomorrow. Items that become effective in the future and are included in the F files will thus not appear in the C file until the time when the effective date is the same as the day after tomorrow. Items having a deadline and that are included in the F files will thus be removed from the C file as soon as their deadline has passed.
For example:

Items with an expiry date before 1-1 for 7 years ago are not distributed to Florecom

Items depending on products, are only distributed when related to at least one product. Such items are : plant, genus, species and cultivar.
This means that the item plant is there when there is at least one product related to that plant.
For to the product related items applies that status of the product as well as the entry and expiry date plays a role by the decision to distribute that item

Product related items are: regulation feature type and product feature type. For these items applies the status of the product as well as the validity of the product feature type and the regulation feature type them self.

Not to the product related items are: feature type, feature group,feature value, regulation type, photo type, group, application, photo reference, language and name type. These items are selected on the basis of entry and expiry dates.

For the item name applies that only names of distribute attributes are being distributed.

4.1.3Update detection

Another principle is that new, expired and changed items are to be detected easily within the complete data set, without the involved business partners being bound to the update frequency of the distribution agent. The code list update fields will allow for this (see § 3.1.2).
To establish which codes are new, expired or changed, the code list processing application needs to record the last processing date and decide which items have been changed since that date, following the next procedure:

new: change_date_time is later than the last processing date/time and entry_date is later than or equal to the change_date
expired: change_date_time is later than the last processing date/time and expiry_date is later than or equal to the change_date
changed: change_date_time is later than the last processing date/time and entry_date is before the change_date.

To warrant a proper functioning of this procedure, VBN and FlorEcom will ensure that:

expired items will be permanently included in the code lists, with the exception of the items mentioned in § 4.1.2 (expired for 7 years)
new or expired items will not be entered or become expired retroactively, but only on the change date or later
changes will not be made retroactively nor announced in advance, but effected on the change date only.
once expired, items will not be reused. It is possible, however, to reactivate items such as a product code. In such a case, a previously distributed expiration date would be removed.

4.1.4Removed

4.1.5Definition of new, expired and changed items

To be able to properly process the code lists, it’s vital to strictly define the terms ‘new’, ‘expired’ and ‘changed’ items:
new: an item, the ID of which has not yet been used before

expired: an item with an existing ID, the expiry date of which has passed

changed: an item with an existing ID, of which the contents of one or more of its attributes has been changed in the database of the code list responsible agency; since not all item attributes in the code list manager’s system need to have been included in the distributed code lists, an item may be marked as changed without this being evident from any visible change in the fields of the involved code list item.
These definitions imply that items whose key fields have changed (e.g.: a change in the regulation type of a regulatory feature type) will be notified as being ‘expired’ (the replaced item) as well as being ‘new’ (the replacing item). If the change does not involve a key field but an attribute field, the item will go notified as ‘changed’. The termination of items does not automatically mean that related items have also reached a deadline.

1 2 3 4 5 6 7 8