Policy:Intake Database - Revision history

Woody: /* Schema Notes */

2022-08-11T14:17:21Z

Schema Notes

Woody: /* Schema Notes */

2022-06-27T11:09:31Z

Schema Notes

Woody at 11:37, 18 May 2022

2022-05-18T11:37:19Z

Woody at 11:30, 18 May 2022

2022-05-18T11:30:35Z

Woody at 14:07, 29 March 2022

2022-03-29T14:07:21Z

Woody: /* Schema Notes */

2022-03-28T14:32:31Z

Schema Notes

Woody: /* Schema Notes */

2022-03-28T13:03:54Z

Schema Notes

Woody: /* Schema Notes */

2022-03-28T12:53:07Z

Schema Notes

Woody: /* Schema Notes */

2022-03-28T12:18:58Z

Schema Notes

Woody: /* Schema Notes */

2022-03-28T12:17:47Z

Schema Notes

@@ Line 14: / Line 14: @@
 * Countries should be canonically indicated by their ISO-3166 Alpha-2 abbreviation where available, and a flag should be used to indicate when a country without an assigned ISO-3166 abbreviation is being identified.
-* Suffixes for companies, such as "LLC," "Joint Stock Company," "Corp," and prefixes and suffixes for people, such as "Jr.," "Honorable," "Eng.," "Ph.D" should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.
+* Suffixes for companies, such as "LLC," "Joint Stock Company," "Corp," and prefixes and suffixes for people, such as "Jr.," "Honorable," "Eng.," "Ph.D" should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and tokenized or harmonized to the degree possible.
 * Relationships between entities should be recorded using standardized forms ("subsidiary," "parent company," "controlling owner," "officer," "director," "father," "step-son," "spouse," with applicable date ranges and sources of authority or information where appropriate. Note that many relationships are asymmetrically bidirectional, and thus also require a directionality property: Aunt-Nephew for instance.  It may be appropriate to use gender-neutral or gender-inclusive relationship names (i.e. use the same relationship to express father-daughter, mother-son, father-son, and mother-daughter) in order to avoid synchronization issues in cases of unknown or changed genders. Many types of relationships are possible, but this category should not be allowed to become overburdened: it may not be necessary to state that a sanctioned individual is the pilot of a sanctioned aircraft, for instance, when the individual and the aircraft are already related to a common sanctioned holding company by employment and ownership, respectively.

← Older revision		Revision as of 11:09, 27 June 2022
Line 3:		Line 3:

	* All sanctions should be published in an XML schema which is standardized across all participating governments.		* All sanctions should be published in an XML schema which is standardized across all participating governments.
		+
		+	* When governments wish to "inherit" one or more sanctioned entities, or a whole sanctions regime, from another government, an "inclusion by reference" external citation record should be used, rather than a new record created. Such a record should consist of the URL of the cited entity, a start date, and a (potentially empty) end date.

	* Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, "sanctions-au-2000-2009.xml" or "sanctions-se-2020-present.xml"		* Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, "sanctions-au-2000-2009.xml" or "sanctions-se-2020-present.xml"

← Older revision		Revision as of 11:37, 18 May 2022
Line 38:		Line 38:
	----		----

−	* When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'' not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, date of record creation, party or process which created the record, start date of link, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource.	+	* When Internet resources are associated with sanctioned entities, they should exist in their own unique tables of IP address, Autonomous System Number, and Domain Name. Each resource should have a start (and potentially end) date which indicates ''its creation and deletion dates'', not the dates at which it was associated with a sanctioned entity. These resources are then linked to sanctioned entities through a table of links, each of which contains, minimally, a unique identifier, pointer to source of authority, sanctioning event or reason, date of record creation, party or process which created the record, start date of link applicability, optional end date of link (or still-in-effect), as well as the unique identifiers of the sanctioned entity and the Internet resource. These links are potentially many-to-many, and multiple links may exist between the same pair of sanctioned entity and resource, at different or overlapping date ranges.

@@ Line 6: / Line 6: @@
 * Each government should provide a single canonical well-known location, containing a single file with all currently-active sanctions imposed by that government regardless of agency and, optionally, separate files archiving expired sanctions by decade (i.e. one file covering January 1, 1980 through December 31, 1989) with sanctions assigned to files by date of imposition. (If a sanction lasted from May 1, 2009 through February 15, 2011, it would be recorded in the 2000-2009 file, not the 2010-2020 file.) A standardized naming scheme should be established based on the ISO 3166 Alpha-2 country code and the year range; for example, "sanctions-au-2000-2009.xml" or "sanctions-se-2020-present.xml"
-* Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, with applicable date ranges and, if appropriate, source of authority or information.
+* Other relevant metadata, like corporation type, gross revenue, gender of person, height and weight of person, should be recorded if available in standardized record types, in standardized (metric) units, with applicable date ranges and, if appropriate, source of authority or information.
-* The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations.  The native version should have a flag set which indicates it as such.  Each transliteration should be flagged as an alias and labeled by the destination language/script.
+* The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations.  The native version should have a flag set which indicates it as such.  Each transliteration should be flagged as an alias and labeled by the destination language/script. Names should be rendered in Unicode and labeled as to script and language.
 * Suffixes for companies, such as "LLC," "Joint Stock Company," "Corp," and prefixes and suffixes for people, such as "Jr.," "Honorable," "Eng.," "Ph.D" should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.
@@ Line 18: / Line 20: @@
 * If an organization is dissolved, or a person dies, a date should be recorded.
-* For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and an identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (though mostly overlapping) date-ranges.
+* For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and a link to a standardized identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (possibly overlapping) date-ranges.
 * Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented.  The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction. Each act of national law or regulation which produces a sanction list, whether new or an amendment to an existing list, should be represented as a unique record, with the national legal action being the unique identifier.
@@ Line 33: / Line 35: @@
 * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.

@@ Line 30: / Line 30: @@
 * The most-commonly-used form of a personal name should be flagged as such.
-* All known identifying numbers (corporate registration numbers, passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.
+* All known identifying numbers (corporate registration numbers, [https://www.gleif.org/en/about-lei/introducing-the-legal-entity-identifier-lei Legal Entity Identifier (LEI)], [https://www.dnb.com/duns-number.html DUNS number], passport numbers, driver's license or ID numbers) should be saved, along with start and end dates of validity, date of issuance, name and location of issuing authority, etc.
 * Identification-issuing authorities should exist in their own separate table of unique entities, with aliases, most-commonly-used-form, structured place names, start and end date of authority, and hierarchical relationship to parent organizations.

@@ Line 1: / Line 1: @@
 == Schema Notes ==
 Since a schema will need to be standardized across many governments, it should be as complete as possible in the first definition, since it will be extraordinarily difficult to revise or expand subsequent to adoption.
 * The most authoritative name of any entity is the version as presented in its native language ''and script''. Not transliterations.  The native version should have a flag set which indicates it as such.

← Older revision		Revision as of 12:17, 28 March 2022
Line 5:		Line 5:

	* Suffixes for companies, such as "LLC," "Joint Stock Company," "Corp," and prefixes and suffixes for people, such as "Jr.," "Honorable," "Eng.," "Ph.D" should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.		* Suffixes for companies, such as "LLC," "Joint Stock Company," "Corp," and prefixes and suffixes for people, such as "Jr.," "Honorable," "Eng.," "Ph.D" should all be separated from the entity name proper, into separate corporate or individual prefix or suffix fields, and harmonized to the degree possible.
		+
		+	* For each name, dates of first and most recent observed use should be attached.
		+
		+	* If an organization is dissolved, or a person dies, a date should be recorded.
		+
		+	* For each sanction, a start date and, eventually, an end date should be attached to the entity-record, along with the identity of the sanctioning entity, and an identifier of the sanctioning event or reason. A single entity-record may have many separate sanction records attached to it, associated with different countries, different events, and different (though mostly overlapping) date-ranges.
		+
		+	* Sanctioning events or reasons should exist in their own table of unique records, including dates of general imposition or retraction, the entity which imposed them, and a canonical reference to the law, regulation, or finding in which the sanction is documented. The dates attached to the overall event need not be specific to the date level, and need not align exactly with the specific dates on which individual entities were added to the sanction.
		+
		+	* A table of meta-sanctioning events should be used to link national sanction events. For instance, a meta "Russia-Ukraine conflict" event with a start date of 2014 might be used to tie together many separate national sanctions imposed by different countries with date ranges 2014-present, 2014-2014, 2014-2015, 2021-present, 2022-present, et cetera.

	* People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: "given name," "patronymic," "family name," "anglicization," "nickname," etc.		* People names should be separated into parts, and each part should be flagged with an order-of-rendering and a type: "given name," "patronymic," "family name," "anglicization," "nickname," etc.