This reference data provides a standard list of values for all Countries, Territories and Geographic areas. This list is intended to standardize the way Countries, Territories and Geographic areas are described in datasets to enable data interoperability and improve data quality. The data dictionary explains what each column means in the list.

The region is the top tier of local government in New Zealand. There are 16 regions of New Zealand (Part 1 of Schedule 2 of the Local Government Act 2002). Eleven are governed by an elected regional council, while five are governed by territorial authorities (the second tier of local government) who also perform the functions of a regional council and thus are known as unitary authorities. These unitary authorities are Auckland Council, Nelson City Council, Gisborne, Tasman, and Marlborough District Councils. The Chatham Islands Council also perform some of the functions of a regional council, but is not strictly a unitary authority. Unitary authorities act as regional councils for the purposes of a wide range of Acts and regulations. Regional council areas are based on water catchment areas. Regional councils are responsible for the administration of many environmental and public transport matters.Regional Councils were established in 1989 after the abolition of the 22 local government regions. The local government act 2002, requires the boundaries of regions to confirm as far as possible to one or more water catchments. When determining regional boundaries, the local Government commission gave consideration to regional communities of interest when selecting water catchments to included in a region. It also considered factors such as natural resource management, land use planning and environmental matters. Some regional boundaries are conterminous with territorial authority boundaries but there are many exceptions. An example is Taupo District, which is split between four regions, although most of its area falls within the Waikato Region. Where territorial local authorities straddle regional council boundaries, the affected area have been statistically defined in complete area units. Generally regional councils contain complete territorial authorities. The unitary authority of the Auckland Council was formed in 2010, under the Local Government (Tamaki Makarau Reorganisation) Act 2009, replacing the Auckland Regional Council and seven territorial authorities.The seaward boundary of any costal regional council is the twelve mile New Zealand territorial limit. Regional councils are defined at meshblock and area unit level.Regional Councils included in the 2013 digital pattern are:Regional Council CodeRegional Council Name01Northland Region02Auckland Region03Waikato Region04Bay of Plenty Region05Gisborne Region06Hawke's Bay Region07Taranaki Region08Manawatu-Wanganui Region09Wellington Region12West Coast Region13Canterbury Region14Otago Region15Southland Region16Tasman Region17Nelson Region18Marlborough Region99Area Outside RegionAs at 1stJuly 2007, Digital Boundary data became freely available.Deriving of Output FilesThe original vertices delineating the meshblock boundary pattern were digitised in 1991 from 1:5,000 scale urban maps and 1:50,000 scale rural maps. The magnitude of error of the original digital points would have been in the range of +/- 10 metres in urban areas and +/- 25 metres in rural areas. Where meshblock boundaries coincide with cadastral boundaries the magnitude of error will be within the range of 1–5 metres in urban areas and 5 - 20 metres in rural areas. This being the estimated magnitude of error of Landonline.The creation of high definition and generalised meshblock boundaries for the 2013 digital pattern and the dissolving of these meshblocks into other geographies/boundaries were completed within Statistics New Zealand using ESRI's ArcGIS desktop suite and the Data Interoperability extension with the following process: 1. Import data and all attribute fields into an ESRI File Geodatabase from LINZ as a shapefile2. Run geometry checks and repairs.3. Run Topology Checks on all data (Must Not Have Gaps, Must Not Overlap), detailed below.4. Generalise the meshblock layers to a 1m tolerance to create generalised dataset. 5. Clip the high definition and generalised meshblock layers to the coastline using land water codes.6. Dissolve all four meshblock datasets (clipped and unclipped, for both generalised and high definition versions) to higher geographies to create the following output data layers: Area Unit, Territorial Authorities, Regional Council, Urban Areas, Community Boards, Territorial Authority Subdivisions, Wards Constituencies and Maori Constituencies for the four datasets. 7. Complete a frequency analysis to determine that each code only has a single record.8. Re-run topology checks for overlaps and gaps.9. Export all created datasets into MapInfo and Shapefile format using the Data Interoperability extension to create 3 output formats for each file. 10. Quality Assurance and rechecking of delivery files.The High Definition version is similar to how the layer exists in Landonline with a couple of changes to fix topology errors identified in topology checking. The following quality checks and steps were applied to the meshblock pattern:Translation of ESRI Shapefiles to ESRI geodatabase datasetThe meshblock dataset was imported into the ESRI File Geodatabase format, required to run the ESRI topology checks. Topology rules were set for each of the layers. Topology ChecksA tolerance of 0.1 cm was applied to the data, which meant that the topology engine validating the data saw any vertex closer than this distance as the same location. A default topology rule of “Must Be Larger than Cluster Tolerance” is applied to all data – this would highlight where any features with a width less than 0.1cm exist. No errors were found for this rule.Three additional topology rules were applied specifically within each of the layers in the ESRI geodatabase – namely “Must Not Overlap”, “Must Not Have Gaps” and “"Area Boundary Must Be Covered By Boundary Of (Meshblock)”. These check that a layer forms a continuous coverage over a surface, that any given point on that surface is only assigned to a single category, and that the dissolved boundaries are identical to the parent meshblock boundaries.Topology Checks Results: There were no errors in either the gap or overlap checks.GeneralisingTo create the generalised Meshblock layer the “Simplify Polygon” geoprocessing tool was used in ArcGIS, with the following parameters:Simplification Algorithm: POINT_REMOVEMaximum Allowable Offset: 1 metreMinimum Area: 1 square metreHandling Topological Errors: RESOLVE_ERRORSClipping of Layers to CoastlineThe processed feature class was then clipped to the coastline. The coastline was defined as features within the supplied Land2013 with codes and descriptions as follows:11- Island – Included12- Mainland – Included21- Inland Water – Included22- Inlet – Excluded23- Oceanic –Excluded33- Other – Included.Features were clipped using the Data Interoperability extension, attribute filter tool. The attribute filter was used on both the generalised and high definition meshblock datasets creating four meshblock layers. Each meshblock dataset also contained all higher geographies and land-water data as attributes. Note: Meshblock 0017001 which is classified as island, was excluded from the clipped meshblock layers, as most of this meshblock is oceanic. Dissolve meshblocks to higher geographiesStatistics New Zealand then dissolved the ESRI meshblock feature classes to the higher geographies, for both the full and clipped dataset, generalised and high definition datasets. To dissolve the higher geographies, a model was built using the dissolver, aggregator and sorter tools, with each output set to include geography code and names within the Data Interoperability extension. Export to MapInfo Format and ShapfilesThe data was exported to MapInfo and Shapefile format using ESRI's Data Interoperability extension Translation tool. Quality Assurance and rechecking of delivery filesThe feature counts of all files were checked to ensure all layers had the correct number of features. This included checking that all multipart features had translated correctly in the new file.

This dataset has the Fast Healthcare Interoperability Resources (FHIR) definition of an element in a resource or an extension. The definition includes:

• Path (name), Cardinality, and data type
• Definitions, usage notes, and requirements
• Default or fixed values
• Constraints, Length limits, and other usage rules
• Terminology Binding
• Mappings to other specifications
• Structural Usage Information

Overview The Office of the Geographer and Global Issues at the U.S. Department of State produces the Large Scale International Boundaries (LSIB) dataset. The current edition is version 11.4 (published 24 February 2025). The 11.4 release contains updated boundary lines and data refinements designed to extend the functionality of the dataset. These data and generalized derivatives are the only international boundary lines approved for U.S. Government use. The contents of this dataset reflect U.S. Government policy on international boundary alignment, political recognition, and dispute status. They do not necessarily reflect de facto limits of control. National Geospatial Data Asset This dataset is a National Geospatial Data Asset (NGDAID 194) managed by the Department of State. It is a part of the International Boundaries Theme created by the Federal Geographic Data Committee. Dataset Source Details Sources for these data include treaties, relevant maps, and data from boundary commissions, as well as national mapping agencies. Where available and applicable, the dataset incorporates information from courts, tribunals, and international arbitrations. The research and recovery process includes analysis of satellite imagery and elevation data. Due to the limitations of source materials and processing techniques, most lines are within 100 meters of their true position on the ground. Cartographic Visualization The LSIB is a geospatial dataset that, when used for cartographic purposes, requires additional styling. The LSIB download package contains example style files for commonly used software applications. The attribute table also contains embedded information to guide the cartographic representation. Additional discussion of these considerations can be found in the Use of Core Attributes in Cartographic Visualization section below. Additional cartographic information pertaining to the depiction and description of international boundaries or areas of special sovereignty can be found in Guidance Bulletins published by the Office of the Geographer and Global Issues: https://hiu.state.gov/data/cartographic_guidance_bulletins/ Contact Direct inquiries to internationalboundaries@state.gov. Direct download: https://data.geodata.state.gov/LSIB.zip Attribute Structure The dataset uses the following attributes divided into two categories: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | Core CC1_GENC3 | Extension CC1_WPID | Extension COUNTRY1 | Core CC2 | Core CC2_GENC3 | Extension CC2_WPID | Extension COUNTRY2 | Core RANK | Core LABEL | Core STATUS | Core NOTES | Core LSIB_ID | Extension ANTECIDS | Extension PREVIDS | Extension PARENTID | Extension PARENTSEG | Extension These attributes have external data sources that update separately from the LSIB: ATTRIBUTE NAME | ATTRIBUTE STATUS CC1 | GENC CC1_GENC3 | GENC CC1_WPID | World Polygons COUNTRY1 | DoS Lists CC2 | GENC CC2_GENC3 | GENC CC2_WPID | World Polygons COUNTRY2 | DoS Lists LSIB_ID | BASE ANTECIDS | BASE PREVIDS | BASE PARENTID | BASE PARENTSEG | BASE The core attributes listed above describe the boundary lines contained within the LSIB dataset. Removal of core attributes from the dataset will change the meaning of the lines. An attribute status of “Extension” represents a field containing data interoperability information. Other attributes not listed above include “FID”, “Shape_length” and “Shape.” These are components of the shapefile format and do not form an intrinsic part of the LSIB. Core Attributes The eight core attributes listed above contain unique information which, when combined with the line geometry, comprise the LSIB dataset. These Core Attributes are further divided into Country Code and Name Fields and Descriptive Fields. County Code and Country Name Fields “CC1” and “CC2” fields are machine readable fields that contain political entity codes. These are two-character codes derived from the Geopolitical Entities, Names, and Codes Standard (GENC), Edition 3 Update 18. “CC1_GENC3” and “CC2_GENC3” fields contain the corresponding three-character GENC codes and are extension attributes discussed below. The codes “Q2” or “QX2” denote a line in the LSIB representing a boundary associated with areas not contained within the GENC standard. The “COUNTRY1” and “COUNTRY2” fields contain the names of corresponding political entities. These fields contain names approved by the U.S. Board on Geographic Names (BGN) as incorporated in the ‘"Independent States in the World" and "Dependencies and Areas of Special Sovereignty" lists maintained by the Department of State. To ensure maximum compatibility, names are presented without diacritics and certain names are rendered using common cartographic abbreviations. Names for lines associated with the code "Q2" are descriptive and not necessarily BGN-approved. Names rendered in all CAPITAL LETTERS denote independent states. Names rendered in normal text represent dependencies, areas of special sovereignty, or are otherwise presented for the convenience of the user. Descriptive Fields The following text fields are a part of the core attributes of the LSIB dataset and do not update from external sources. They provide additional information about each of the lines and are as follows: ATTRIBUTE NAME | CONTAINS NULLS RANK | No STATUS | No LABEL | Yes NOTES | Yes Neither the "RANK" nor "STATUS" fields contain null values; the "LABEL" and "NOTES" fields do. The "RANK" field is a numeric expression of the "STATUS" field. Combined with the line geometry, these fields encode the views of the United States Government on the political status of the boundary line. A value of “1” in the “RANK” field corresponds to an "International Boundary" value in the “STATUS” field. Values of ”2” and “3” correspond to “Other Line of International Separation” and “Special Line,” respectively. The “LABEL” field contains required text to describe the line segment on all finished cartographic products, including but not limited to print and interactive maps. The “NOTES” field contains an explanation of special circumstances modifying the lines. This information can pertain to the origins of the boundary lines, limitations regarding the purpose of the lines, or the original source of the line. Use of Core Attributes in Cartographic Visualization Several of the Core Attributes provide information required for the proper cartographic representation of the LSIB dataset. The cartographic usage of the LSIB requires a visual differentiation between the three categories of boundary lines. Specifically, this differentiation must be between: - International Boundaries (Rank 1); - Other Lines of International Separation (Rank 2); and - Special Lines (Rank 3). Rank 1 lines must be the most visually prominent. Rank 2 lines must be less visually prominent than Rank 1 lines. Rank 3 lines must be shown in a manner visually subordinate to Ranks 1 and 2. Where scale permits, Rank 2 and 3 lines must be labeled in accordance with the “Label” field. Data marked with a Rank 2 or 3 designation does not necessarily correspond to a disputed boundary. Please consult the style files in the download package for examples of this depiction. The requirement to incorporate the contents of the "LABEL" field on cartographic products is scale dependent. If a label is legible at the scale of a given static product, a proper use of this dataset would encourage the application of that label. Using the contents of the "COUNTRY1" and "COUNTRY2" fields in the generation of a line segment label is not required. The "STATUS" field contains the preferred description for the three LSIB line types when they are incorporated into a map legend but is otherwise not to be used for labeling. Use of the “CC1,” “CC1_GENC3,” “CC2,” “CC2_GENC3,” “RANK,” or “NOTES” fields for cartographic labeling purposes is prohibited. Extension Attributes Certain elements of the attributes within the LSIB dataset extend data functionality to make the data more interoperable or to provide clearer linkages to other datasets. The fields “CC1_GENC3” and “CC2_GENC” contain the corresponding three-character GENC code to the “CC1” and “CC2” attributes. The code “QX2” is the three-character counterpart of the code “Q2,” which denotes a line in the LSIB representing a boundary associated with a geographic area not contained within the GENC standard. To allow for linkage between individual lines in the LSIB and World Polygons dataset, the “CC1_WPID” and “CC2_WPID” fields contain a Universally Unique Identifier (UUID), version 4, which provides a stable description of each geographic entity in a boundary pair relationship. Each UUID corresponds to a geographic entity listed in the World Polygons dataset. These fields allow for linkage between individual lines in the LSIB and the overall World Polygons dataset. Five additional fields in the LSIB expand on the UUID concept and either describe features that have changed across space and time or indicate relationships between previous versions of the feature. The “LSIB_ID” attribute is a UUID value that defines a specific instance of a feature. Any change to the feature in a lineset requires a new “LSIB_ID.” The “ANTECIDS,” or antecedent ID, is a UUID that references line geometries from which a given line is descended in time. It is used when there is a feature that is entirely new, not when there is a new version of a previous feature. This is generally used to reference countries that have dissolved. The “PREVIDS,” or Previous ID, is a UUID field that contains old versions of a line. This is an additive field, that houses all Previous IDs. A new version of a feature is defined by any change to the feature—either line geometry or attribute—but it is still conceptually the same feature. The “PARENTID” field

SeaLiT Knowledge Graphs is an RDF dataset of maritime history data that has been transcribed (and then transformed) from original archival sources in the context of the SeaLiT Project (Seafaring Lives in Transition, Mediterranean Maritime Labour and Shipping, 1850s-1920s). The underlying data model is the SeaLiT Ontology, an extension of the ISO standard CIDOC-CRM (ISO 21127:2014) for the modelling and integration of maritime history information.

The knowledge graphs integrate data of totally 16 different types of archival sources:

• Crew Lists
  • Crew and displacement list (Roll)
  • Crew List (Ruoli di Equipaggio)
  • General Spanish Crew List
• Registers / Lists
  • Students Register
  • Civil Register
  • Register of Maritime Personnel
  • Register of Maritime Workers (Matricole della gente di mare)
  • Sailors Register (Libro de registro de marineros)
  • Naval Ship Register List
  • Seagoing Personnel
  • Lists of ships
• Censuses
  • Census La Ciotat
  • First National all-Russian Census of the Russian Empire
• Payrolls
  • Payrolls of private archives and libraries in Greece
  • Payrolls of Russian Steam Navigation and Trading Company
• Employment records
  • Shipyards of Messageries Maritimes, La Ciotat

More information about the archival sources are available through the SeaLiT website. Data exploration applications over these sources are also publicly available (SeaLiT Catalogues, SeaLiT ResearchSpace).

Data from these archival sources has been transcribed in tabular form and then curated by historians of SeaLiT using the FAST CAT system. The transcripts (records), together with the curated vocabulary terms and entity instances (ships, persons, locations, organizations), are then transformed to RDF using the SeaLiT Ontology as the target (domain) model. To this end, the corresponding schema mappings between the original schemata and the ontology were defined using the X3ML mapping definition language, that were subsequently used for delivering the RDF datasets.

More information about the FAST CAT system and the data transcription, curation and transformation processes can be found in the following paper:

P. Fafalios, K. Petrakis, G. Samaritakis, K. Doerr, A. Kritsotaki, Y. Tzitzikas, M. Doerr, "FAST CAT: Collaborative Data Entry and Curation for Semantic Interoperability in Digital Humanities", ACM Journal on Computing and Cultural Heritage, 2021. https://doi.org/10.1145/3461460 [pdf, bib]

The RDF dataset is provided as a set of TriG files per record per archival source. For each record, the dataset provides: i) one trig file for the record's data (records.trig), ii) one trig file for the record's (curated) vocabulary terms (vocabularies.trig), and iii) four trig files for the record's (curated) entity instances (ships.trig, persons.trig, persons.trig, organizations.trig).

We also provide the RDFS files of the used ontologies (SeaLiT Ontology verson 1.0, CIDOC-CRM version 7.1.1).

The NHS Business Services Authority (NHSBSA) publishes Secondary Care Medicines Data on behalf of NHS England (NHSE). This dataset provides 'Provisional' Secondary Care Medicines data for all NHS Acute, Teaching, Specialist, Mental Health, and Community Trusts in England. It provides information on pharmacy stock control, reflecting processed medicines data. RX Info is responsible for refreshing the Provisional data at the close of each financial year to include backtracking adjustments. The data is 'Finalised' to provide validated and complete figures for each reporting period, incorporating any updates and corrections throughout the year. The Finalised dataset serves as the definitive record for each month and year, offering the most accurate information on medicines issued. While we do not analyse changes, users can compare the finalised data with provisional data to identify any discrepancies. Key Components of the Data Quantities of Medicines Issued: Details the total quantities of medicines stock control via NHS Secondary Care services. Indicative Costs: Actual costs cannot be displayed in the dataset as NHS Hospital pricing contracts and NICE Patient Access Schemes are confidential. The indicative cost of medicines is derived from current medicines pricing data held in NHSBSA data systems (Common Drug Reference and dm+d), calculated to VMP level. Indicative costs are calculated using: Community pharmacy reimbursement prices for generic medicines. List prices for branded medicines. Care should be taken when interpreting and analysing this indicative cost as it does not reflect the net actual cost of NHS Trusts, which will differ due to the application of confidential discounts, rebates, or procurement agreements paid by hospitals when purchasing medicines. Standardisation with SNOMED CT and dm+d: SNOMED CT (Systematised Nomenclature of Medicine - Clinical Terms) is used to enhance the dataset’s compatibility with electronic health record systems and clinical decision support tools. SNOMED CT is a globally recognised coding system that provides precise definitions for clinical terms, ensuring interoperability across healthcare systems. Trust-Level Data: Data is broken down by individual NHS Trusts, enabling regional comparisons, benchmarking, and targeted analysis of specific Trusts. Medicine Identification: Medicines in the dataset are identified using Virtual Medicinal Product (VMP) codes from the Dictionary of Medicines and Devices (dm+d): VMP_PRODUCT_NAME: The name of the Virtual Medicinal Product (VMP) as defined by the dm+d, which includes key details about the product. For example: Paracetamol 500mg tablets. VMP_SNOMED_CODE: The code for the Virtual Medicinal Product (VMP), providing a unique identifier for each product. For example: 42109611000001109 represents Paracetamol 500mg tablets. You can access the finalised files in our Finalised Secondary Care Medicines Data (SCMD) with indicative price dataset.

Objective: To develop a clinical informatics pipeline designed to capture large-scale structured EHR data for a national patient registry.

Materials and Methods: The EHR-R-REDCap pipeline is implemented using R-statistical software to remap and import structured EHR data into the REDCap-based multi-institutional Merkel Cell Carcinoma (MCC) Patient Registry using an adaptable data dictionary.

Results: Clinical laboratory data were extracted from EPIC Clarity across several participating institutions. Labs were transformed, remapped and imported into the MCC registry using the EHR labs abstraction (eLAB) pipeline. Forty-nine clinical tests encompassing 482,450 results were imported into the registry for 1,109 enrolled MCC patients. Data-quality assessment revealed highly accurate, valid labs. Univariate modeling was performed for labs at baseline on overall survival (N=176) using this clinical informatics pipeline.

Conclusion: We demonstrate feasibility of the facile eLAB workflow. EHR data is successfully transformed, and bulk-loaded/imported into a REDCap-based national registry to execute real-world data analysis and interoperability.

Methods eLAB Development and Source Code (R statistical software):

eLAB is written in R (version 4.0.3), and utilizes the following packages for processing: DescTools, REDCapR, reshape2, splitstackshape, readxl, survival, survminer, and tidyverse. Source code for eLAB can be downloaded directly (https://github.com/TheMillerLab/eLAB).

eLAB reformats EHR data abstracted for an identified population of patients (e.g. medical record numbers (MRN)/name list) under an Institutional Review Board (IRB)-approved protocol. The MCCPR does not host MRNs/names and eLAB converts these to MCCPR assigned record identification numbers (record_id) before import for de-identification.

Functions were written to remap EHR bulk lab data pulls/queries from several sources including Clarity/Crystal reports or institutional EDW including Research Patient Data Registry (RPDR) at MGB. The input, a csv/delimited file of labs for user-defined patients, may vary. Thus, users may need to adapt the initial data wrangling script based on the data input format. However, the downstream transformation, code-lab lookup tables, outcomes analysis, and LOINC remapping are standard for use with the provided REDCap Data Dictionary, DataDictionary_eLAB.csv. The available R-markdown ((https://github.com/TheMillerLab/eLAB) provides suggestions and instructions on where or when upfront script modifications may be necessary to accommodate input variability.

The eLAB pipeline takes several inputs. For example, the input for use with the ‘ehr_format(dt)’ single-line command is non-tabular data assigned as R object ‘dt’ with 4 columns: 1) Patient Name (MRN), 2) Collection Date, 3) Collection Time, and 4) Lab Results wherein several lab panels are in one data frame cell. A mock dataset in this ‘untidy-format’ is provided for demonstration purposes (https://github.com/TheMillerLab/eLAB).

Bulk lab data pulls often result in subtypes of the same lab. For example, potassium labs are reported as “Potassium,” “Potassium-External,” “Potassium(POC),” “Potassium,whole-bld,” “Potassium-Level-External,” “Potassium,venous,” and “Potassium-whole-bld/plasma.” eLAB utilizes a key-value lookup table with ~300 lab subtypes for remapping labs to the Data Dictionary (DD) code. eLAB reformats/accepts only those lab units pre-defined by the registry DD. The lab lookup table is provided for direct use or may be re-configured/updated to meet end-user specifications. eLAB is designed to remap, transform, and filter/adjust value units of semi-structured/structured bulk laboratory values data pulls from the EHR to align with the pre-defined code of the DD.

Data Dictionary (DD)

EHR clinical laboratory data is captured in REDCap using the ‘Labs’ repeating instrument (Supplemental Figures 1-2). The DD is provided for use by researchers at REDCap-participating institutions and is optimized to accommodate the same lab-type captured more than once on the same day for the same patient. The instrument captures 35 clinical lab types. The DD serves several major purposes in the eLAB pipeline. First, it defines every lab type of interest and associated lab unit of interest with a set field/variable name. It also restricts/defines the type of data allowed for entry for each data field, such as a string or numerics. The DD is uploaded into REDCap by every participating site/collaborator and ensures each site collects and codes the data the same way. Automation pipelines, such as eLAB, are designed to remap/clean and reformat data/units utilizing key-value look-up tables that filter and select only the labs/units of interest. eLAB ensures the data pulled from the EHR contains the correct unit and format pre-configured by the DD. The use of the same DD at every participating site ensures that the data field code, format, and relationships in the database are uniform across each site to allow for the simple aggregation of the multi-site data. For example, since every site in the MCCPR uses the same DD, aggregation is efficient and different site csv files are simply combined.

Study Cohort

This study was approved by the MGB IRB. Search of the EHR was performed to identify patients diagnosed with MCC between 1975-2021 (N=1,109) for inclusion in the MCCPR. Subjects diagnosed with primary cutaneous MCC between 2016-2019 (N= 176) were included in the test cohort for exploratory studies of lab result associations with overall survival (OS) using eLAB.

Statistical Analysis

OS is defined as the time from date of MCC diagnosis to date of death. Data was censored at the date of the last follow-up visit if no death event occurred. Univariable Cox proportional hazard modeling was performed among all lab predictors. Due to the hypothesis-generating nature of the work, p-values were exploratory and Bonferroni corrections were not applied.

Neuroscientists employ a range of methods and generate increasing amounts of data describing brain structure and function. The anatomical locations from which observations or measurements originate represent a common context for data interpretation, and a starting point for identifying data of interest. However, the multimodality and abundance of brain data pose a challenge for efforts to organize, integrate, and analyze data based on anatomical locations. While structured metadata allow faceted data queries, different types of data are not easily represented in a standardized and machine-readable way that allow comparison, analysis, and queries related to anatomical relevance. To this end, three-dimensional (3D) digital brain atlases provide frameworks in which disparate multimodal and multilevel neuroscience data can be spatially represented. We propose to represent the locations of different neuroscience data as geometric objects in 3D brain atlases. Such geometric objects can be specified in a standardized file format and stored as location metadata for use with different computational tools. We here present the Locare workflow developed for defining the anatomical location of data elements from rodent brains as geometric objects. We demonstrate how the workflow can be used to define geometric objects representing multimodal and multilevel experimental neuroscience in rat or mouse brain atlases. We further propose a collection of JSON schemas (LocareJSON) for specifying geometric objects by atlas coordinates, suitable as a starting point for co-visualization of different data in an anatomical context and for enabling spatial data queries.

Australia's Land Borders is a product within the Foundation Spatial Data Framework (FSDF) suite of datasets. It is endorsed by the ANZLIC - the Spatial Information Council and the Intergovernmental Committee on Surveying and Mapping (ICSM) as a nationally consistent and topologically correct representation of the land borders published by the Australian states and territories.

The purpose of this product is to provide: (i) a building block which enables development of other national datasets; (ii) integration with other geospatial frameworks in support of data analysis; and (iii) visualisation of these borders as cartographic depiction on a map. Although this dataset depicts land borders, it is not nor does it suggests to be a legal definition of these borders. Therefore it cannot and must not be used for those use-cases pertaining to legal context.

This product is constructed by Geoscience Australia (GA), on behalf of the ICSM, from authoritative open data published by the land mapping agencies in their respective Australian state and territory jurisdictions. Construction of a nationally consistent dataset required harmonisation and mediation of data issues at abutting land borders. In order to make informed and consistent determinations, other datasets were used as visual aid in determining which elements of published jurisdictional data to promote into the national product. These datasets include, but are not restricted to: (i) PSMA Australia's commercial products such as the cadastral (property) boundaries (CadLite) and Geocoded National Address File (GNAF); (ii) Esri's World Imagery and Imagery with Labels base maps; and (iii) Geoscience Australia's GEODATA TOPO 250K Series 3. Where practical, Land Borders do not cross cadastral boundaries and are logically consistent with addressing data in GNAF.

It is important to reaffirm that although third-party commercial datasets are used for validation, which is within remit of the licence agreement between PSMA and GA, no commercially licenced data has been promoted into the product. Australian Land Borders are constructed exclusively from published open data originating from state, territory and federal agencies.

This foundation dataset consists of edges (polylines) representing mediated segments of state and/or territory borders, connected at the nodes and terminated at the coastline defined as the Mean High Water Mark (MHWM) tidal boundary. These polylines are attributed to convey information about provenance of the source. It is envisaged that land borders will be topologically interoperable with the future national coastline dataset/s, currently being built through the ICSM coastline capture collaboration program. Topological interoperability will enable closure of land mass polygon, permitting spatial analysis operations such as vector overly, intersect, or raster map algebra. In addition to polylines, the product incorporates a number of well-known survey-monumented corners which have historical and cultural significance associated with the place name.

This foundation dataset is constructed from the best-available data, as published by relevant custodian in state and territory jurisdiction. It should be noted that some custodians - in particular the Northern Territory and New South Wales - have opted out or to rely on data from abutting jurisdiction as an agreed portrayal of their border. Accuracy and precision of land borders as depicted by spatial objects (features) may vary according to custodian specifications, although there is topological coherence across all the objects within this integrated product. The guaranteed minimum nominal scale for all use-cases, applying to complete spatial coverage of this product, is 1:25 000. In some areas the accuracy is much better and maybe approaching cadastre survey specification, however, this is an artefact of data assembly from disparate sources, rather than the product design. As the principle, no data was generalised or spatially degraded in the process of constructing this product.

Some use-cases for this product are: general digital and web map-making applications; a reference dataset to use for cartographic generalisation for a smaller-scale map applications; constraining geometric objects for revision and updates to the Mesh Blocks, the building blocks for the larger regions of the Australian Statistical Geography Standard (ASGS) framework; rapid resolution of cross-border data issues to enable construction and visual display of a common operating picture, etc.

This foundation dataset will be maintained at irregular intervals, for example if a state or territory jurisdiction decides to publish or republish their land borders. If there is a new version of this dataset, past version will be archived and information about the changes will be made available in the change log.

Australia's Land Borders is a product within the Foundation Spatial Data Framework (FSDF) suite of datasets. It is endorsed by the ANZLIC - the Spatial Information Council and the Intergovernmental …Show full descriptionAustralia's Land Borders is a product within the Foundation Spatial Data Framework (FSDF) suite of datasets. It is endorsed by the ANZLIC - the Spatial Information Council and the Intergovernmental Committee on Surveying and Mapping (ICSM) as a nationally consistent and topologically correct representation of the land borders published by the Australian states and territories. The purpose of this product is to provide: (i) a building block which enables development of other national datasets; (ii) integration with other geospatial frameworks in support of data analysis; and (iii) visualisation of these borders as cartographic depiction on a map. Although this dataset depicts land borders, it is not nor does it suggests to be a legal definition of these borders. Therefore it cannot and must not be used for those use-cases pertaining to legal context. This product is constructed by Geoscience Australia (GA), on behalf of the ICSM, from authoritative open data published by the land mapping agencies in their respective Australian state and territory jurisdictions. Construction of a nationally consistent dataset required harmonisation and mediation of data issues at abutting land borders. In order to make informed and consistent determinations, other datasets were used as visual aid in determining which elements of published jurisdictional data to promote into the national product. These datasets include, but are not restricted to: (i) PSMA Australia's commercial products such as the cadastral (property) boundaries (CadLite) and Geocoded National Address File (GNAF); (ii) Esri's World Imagery and Imagery with Labels base maps; and (iii) Geoscience Australia's GEODATA TOPO 250K Series 3. Where practical, Land Borders do not cross cadastral boundaries and are logically consistent with addressing data in GNAF. It is important to reaffirm that although third-party commercial datasets are used for validation, which is within remit of the licence agreement between PSMA and GA, no commercially licenced data has been promoted into the product. Australian Land Borders are constructed exclusively from published open data originating from state, territory and federal agencies. This foundation dataset consists of edges (polylines) representing mediated segments of state and/or territory borders, connected at the nodes and terminated at the coastline defined as the Mean High Water Mark (MHWM) tidal boundary. These polylines are attributed to convey information about provenance of the source. It is envisaged that land borders will be topologically interoperable with the future national coastline dataset/s, currently being built through the ICSM coastline capture collaboration program. Topological interoperability will enable closure of land mass polygon, permitting spatial analysis operations such as vector overly, intersect, or raster map algebra. In addition to polylines, the product incorporates a number of well-known survey-monumented corners which have historical and cultural significance associated with the place name. This foundation dataset is constructed from the best-available data, as published by relevant custodian in state and territory jurisdiction. It should be noted that some custodians - in particular the Northern Territory and New South Wales - have opted out or to rely on data from abutting jurisdiction as an agreed portrayal of their border. Accuracy and precision of land borders as depicted by spatial objects (features) may vary according to custodian specifications, although there is topological coherence across all the objects within this integrated product. The guaranteed minimum nominal scale for all use-cases, applying to complete spatial coverage of this product, is 1:25 000. In some areas the accuracy is much better and maybe approaching cadastre survey specification, however, this is an artefact of data assembly from disparate sources, rather than the product design. As the principle, no data was generalised or spatially degraded in the process of constructing this product. Some use-cases for this product are: general digital and web map-making applications; a reference dataset to use for cartographic generalisation for a smaller-scale map applications; constraining geometric objects for revision and updates to the Mesh Blocks, the building blocks for the larger regions of the Australian Statistical Geography Standard (ASGS) framework; rapid resolution of cross-border data issues to enable construction and visual display of a common operating picture, etc. This foundation dataset will be maintained at irregular intervals, for example if a state or territory jurisdiction decides to publish or republish their land borders. If there is a new version of this dataset, past version will be archived and information about the changes will be made available in the change log.

The Guidelines specify the interoperability layer between Current Research Information Systems (CRIS) and the OpenAIRE infrastructure. The information interchange is based on the Common European Research Information Format (CERIF) data model, the CERIF XML exchange format, and the OAI-PMH protocol. The Guidelines are intended mainly for implementers and administrators of CRIS who plan to communicate research information to OpenAIRE. OpenAIRE (openaire.eu) is the European infrastructure enabling researchers to comply with the European Union requirements for Open Access to research results. OpenAIRE collects metadata from a variety of data sources: publication repositories, data archives and CRIS across Europe and beyond. Interoperability guidelines are defined for each type of source. CERIF is a standard data model for research information and a recommendation by the European Union to its Member States. The custody of CERIF has been entrusted by the European Union to euroCRIS (eurocris.org), an international not-for-profit organisation dedicated to the interoperability of CRIS.

The NIST Extensible Resource Data Model (NERDm) is a set of schemas for encoding in JSON format metadatathat describe digital resources. The variety of digital resources it can describe includes not onlydigital data sets and collections, but also software, digital services, web sites and portals, anddigital twins. It was created to serve as the internal metadata format used by the NIST Public DataRepository and Science Portal to drive rich presentations on the web and to enable discovery; however, itwas also designed to enable programmatic access to resources and their metadata by external users.Interoperability was also a key design aim: the schemas are defined using the JSON Schema standard,metadata are encoded as JSON-LD, and their semantics are tied to community ontologies, with an emphasison DCAT and the US federal Project Open Data (POD) models. Finally, extensibility is also central to itsdesign: the schemas are composed of a central core schema and various extension schemas. New extensionsto support richer metadata concepts can be added over time without breaking existing applications.Validation is central to NERDm's extensibility model. Consuming applications should be able to choosewhich metadata extensions they care to support and ignore terms and extensions they don't support.Furthermore, they should not fail when a NERDm document leverages extensions they don't recognize, evenwhen on-the-fly validation is required. To support this flexibility, the NERDm framework allowsdocuments to declare what extensions are being used and where. We have developed an optional extensionto the standard JSON Schema validation (see ejsonschema below) to support flexible validation: while astandard JSON Schema validater can validate a NERDm document against the NERDm core schema, our extensionwill validate a NERDm document against any recognized extensions and ignore those that are notrecognized.The NERDm data model is based around the concept of resource, semantically equivalent to a schema.orgResource, and as in schema.org, there can be different types of resources, such as data sets andsoftware. A NERDm document indicates what types the resource qualifies as via the JSON-LD "@type"property. All NERDm Resources are described by metadata terms from the core NERDm schema; however,different resource types can be described by additional metadata properties (often drawing on particularNERDm extension schemas). A Resource contains Components of various types (includingDCAT-defined Distributions) that are considered part of the Resource; specifically, these can include downloadable data files, hierachical datacollecitons, links to web sites (like software repositories), software tools, or other NERDm Resources.Through the NERDm extension system, _domain-specific metadata can be included at either the resource orcomponent level. The direct semantic and syntactic connections to the DCAT, POD, and schema.org schemasis intended to ensure unambiguous conversion of NERDm documents into those schemas.As of this writing, the Core NERDm schema and its framework stands at version 0.7 and is compatible withthe "draft-04" version of JSON Schema. Version 1.0 is projected to be released in 2025. In thatrelease, the NERDm schemas will be updated to the "draft2020" version of JSON Schema. Other improvementswill include stronger support for RDF and the Linked Data Platform through its support of JSON-LD.

The Australian Sport Thesaurus is an accumulation of over 15,000 terms and definitions covering concepts and objects related to sport and sporting organisations with a strong emphasis on Australian …Show full descriptionThe Australian Sport Thesaurus is an accumulation of over 15,000 terms and definitions covering concepts and objects related to sport and sporting organisations with a strong emphasis on Australian sport. It is an evolving project and not all definitions have been verified and therefore we are seeking input from the sporting community to help us improve this product. The Thesaurus is in the most part a controlled vocabulary that aims to reduce ambiguity in sporting terminology by providing authorised terms for every sport and sporting activity. Having defined preferred and non-preferred terms within sport is intended to promote consistency in terminology across the entire sporting community. While at this stage it is called a Thesaurus, in the longer term it is hoped that the product becomes a sports metadata register for the purpose of creating data standards for data exchange and interoperability. The Australian Sports Thesaurus seeks to provide clarity and assistance to the sport community by: ensuring consistency of understanding and usage of sport terminology in documentary, legal and commercial discussions enabling improved system and database interoperability and reporting facilitating search and retrieval of information from sport information systems facilitating the defining of sport data for Data Dictionaries. The terms and definitions are where relevant linked by the following relationships: +Preferred term +Non-preferred term +Broader term +Narrower term +Related term

The is an online map-based user interface which allows users to discover and access Earth observation data and resources from different providers from all over the world.The portal is implemented and operated by the European Space Agency and provides a single internet discovery and access point to the ever-growing quantities of heterogeneous collections of Earth observations from satellites, airplanes, drones and in-situ sensors at global, regional and local scales through the Global Earth Observation System of Systems (GEOSS).The GEOSS is a social and software ecosystem connecting a large array of observing systems, data systems and processing services to strengthen monitoring of the state of the Earth. It facilitates data and information accessibility and interoperability to support the Sustainable Development Goals (SDG) agenda and the Disaster Risk Reduction.The GEOSS Platform is the cornerstone around which the GEOSS software ecosystem is implemented. The GEOSS Platform is the “glueware” that enables the connection and coordination of the many autonomous and multi-organizational systems and services contributing to GEOSS.The figure above provides an overview of the GEOSS Platform and its main components:The GEOSS Portal.The GEO Discovery and Access Broker (GEO DAB) is the primary mechanism by which all data and information is discovered and accessed. The GEO DAB implements the necessary mediation and harmonization services through Application Program Interfaces (APIs). These APIs allow data providers to share resources without having to make major changes to their technology or standards.The GEOSS Yellow pages service implements the simplified registration process for new Data Providers.The GEOSS Service Status Checker is the component, developed by USGS/FGDC and integrated into the GEO DAB, which aims at improving user experience by providing information on Reliability of Services. The Status Checker is an automatic mechanism to monitor, diagnose and alert data providers and users on the Health status of the web services provided by the GEOSS Platform.In addition to the above described main components of the Platform, GEOSS offers the so-called Reuse Components to serve the specificities of the various user communities. This means that user communities, which might have their own data, portals and corresponding specific needs, can reuse some of the GEOSS Platform components customized and tailored to their specific requirements.The Reuse Components are:The GEOSS View, which provides access to a subset of specifically defined GEOSS resources using temporal, thematic and spatial criteria;The GEOSS APIs, which expose the discovery and access functionalities of the GEO DAB and as such can be exploited by user communities’ client applications or portals;The GEOSS Mirror is a GEOSS Portal site customisation for SBAs, Flagships, Initiatives, and Communities. The customisation better serves the specific community interests by filtering catalogues and search results by a specific theme or GEO DAB view, location of interest, etc.;The GEOSS Widget is a freely-available instantiation of selected GEOSS Portal widgets made available for possible customization in various areas of application (e.g. a specific SBA, Initiatives, etc.). This is accomplished by publishing portal code parts (widgets) wrapped up in API. The GEOSS Portal and the GEOS DAB evolved thanks to ESA-EC collaboration and have become more user-centric. Different developments are already available from the Operational Portal which is basically focused on discovery and access to data, others are provided as proof of concept in a development portal which is moving towards handling information and services to provide users with the possibility to acquire knowledge and take well-informed decisions.Follow this link https://prezi.com/view/Z68hB3z0c2d95hdKLSGh/ to have a number of scenarios at your fingertips. Send an email to GEOSS Portal Team for any further clarification or feedback. Current versionThe GEOSS Portal has been updated for a more intuitive and fluid user experience.The main updates and functionalities are listed below:Updated advanced search panel;Updated data results page layout;GEOSS View self-definition and use (available in MyWorkSpace after sign-in);History navigation;Instant feedback.