Available Technology JSON

Available Technology JSON

Overview

How to use Project Open Data Metadata Schema guidelines to document and list agency datasets and application programming interfaces (APIs) for hosting at agency.gov/data and currently in use at data.gov

Details

Specification Name: FLC Schema v1.1 (Available Technology JSON)
This version: 1.1
Latest version: This version
Publication date: April 1st 2021

Introduction

The Federal Laboratory Consortium for Technology Transfer (FLC) is the formally chartered, nationwide network of over 300 federal laboratories, agencies, and research centers that fosters commercialisation best practice strategies and opportunities for accelerating federal technologies from out of the labs and into the marketplace.

This Document is for detailed description to Pull Data for the Available Technologies from the FLC application.

Standard Metadata Vocabulary

Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource (NISO 2004, ISBN: 1-880124-62-9). The challenge is to define and name standard metadata fields so that a data consumer has sufficient information to process and understand the described data. The more information that can be conveyed in a standardized regular format, the more valuable data becomes. Metadata can range from basic to advanced, from allowing one to discover the mere fact that a certain data asset exists and is about a general subject all the way to providing detailed information documenting the structure, processing history, quality, relationships, and other properties of a dataset. Making metadata machine readable greatly increases its utility, but requires more detailed standardization, defining not only field names, but also how information is encoded in the metadata fields.

Establishing a common vocabulary is the key to communication. The metadata schema specified in this memorandum is based on DCAT, a hierarchical vocabulary specific to datasets. This specification defines three types of metadata elements: Required, Required-if (conditionally required), and Expanded fields. These elements were selected to represent information that is most often looked for on the web. To assist users of other metadata standards, field mappings to equivalent elements in other standards are provided.

What to Document – Datasets and Web APIs

A dataset is an identifiable collection of structured data objects unified by some criteria (authorship, subject, scope, spatial or temporal extent…). A catalog is a collection of descriptions of datasets; each description is a metadata record. The intention of a data catalog is to facilitate data access by users who are first interested in a particular kind of data, and upon finding a fit-for-purpose dataset, will next want to know how to get the data.

A Web API (Application Programming Interface) allows computer programs to dynamically query a dataset using the World Wide Web. For example, a dataset of farmers markets may be made available for download as a single file (e.g., a CSV), or may be made available to developers through a Web API, such that a computer program could use a ZIP Code to retrieve a list of farmers markets in the ZIP Code area.

The catalog file for each agency should list all of the agency’s datasets that can be made public, regardless of whether they are distributed by a file download or a Web API. Please also see the extended guidance on documenting Web APIs in your data.json files.

Extending the Schema

“Extensional” and/or domain specific metadata can easily be added using other vocabularies even if it is not a term (entity/property) that will get indexed by the major search engines - it could still be indexed by other custom search engines and by Data.gov. Publishers are encouraged to extend their metadata descriptions using elements from the “Expanded Fields” list shown below, or from any well-known vocabulary (including Dublin Core, Schema.org, FGDC, ISO 19115, and NIEM) as long as they are properly assigned. It’s also recommended that these extensions be defined through the describedBy and @context fields at the top of the Catalog metadata.

Further Metadata Field Guidance

  • Key
    • Required
    • Required if Applicable
    • Expanded (optional)
{

  "nodes" : {

    "{{nid}}" : {

      "title" : ["PROPHYLACTIC AND THERAPEUTIC MONOCLONAL.."],

      "agency" : ["Dept. of Commerce"],

      "internal_laboratory_ref" : ["20-055"],

      "patent_number" : ["10,756,263"],

      "abstract" : ["PHASE TRANSITION BASED RESISTIVE RANDOM-ACCESS.."],

      "applications" : [ "applications.."],

      "benefits" : ["Advantages of the proposed.."],

      "body" : ["This invention relates to memory devices, in particular.."],

      "inventors" : [ "Joerg Appenzeller"],

      "inventors_text" : ["Joerg Appenzeller, Feng Zhang, Yuqi Zhu, .."],

      "licensing_availability" : [ "Exclusive"],

      "patent_issue_date" : ["2020-08-25"],

      "patent_status" : ["Pending"],

      "sub_title" : ["sub title"],

      "tech_areas" : [""],

      "tech_disciplines" : ["Electronics & Hardware"],

      "technology_types" : ["Materials for electronics, Electron Physics, Electronics"],

      "state" : [ "Maryland"],

      "tech_area" : ["Homeland Security, Dimensional, Information Technology, .."],

      "lab" : ["National Institute of Standards and Technology - NIST"],

      "region" : ["Mid-Atlantic"],

      "security_lab" : ["Non Security Lab"],

      "owner_code" : ["Government Owned, Government Operated"],

      "reps" : ["Joerg Appenzeller, Feng Zhang, Yuqi Zhu, .."],

      "reference_code" : ["reference_code value"],

      "documents" : ["document value"],

      "images" : [ "https://18833-flc.pantheonsite.io/sites/default/files/.."]

      "conformsTo" : [ "Not Available" ],

      "dataset" : [ "Not Available" ],

      "accessLevel" : [ "Not Available" ],

      "bureauCode" : [ "Not Available" ],

      "contactPoint" : [ "Not Available" ],

      "description" : [ "Not Available" ],

      "identifier" : [ "Not Available" ],

      "keyword" : [ "Not Available" ],

      "modified" : [ "Not Available" ],
      
      "programCode" : [ "Not Available" ],

      "publisher" : [ "Not Available" ],

      "name" : [ "Not Available" ],

      "fn" : [ "Not Available" ],

      "hasEmail" : [ "Not Available" ] }
  }

}
Field title
Required Yes
Accepted Values String
Example "title":["Novel Redox Shuttles for Overcharge Protection of Lithium-Ion Batteries"]
Field agency
Required No
Accepted Values String (URL)
Example "agency" : ["Dept. of Commerce"]
Field Internal Laboratory Ref #
Required No
Accepted Values String
Example "internal_laboratory_ref" : ["20-055"]
Field Patent Number
Required No
Accepted Values String
Example "patent_number" : ["10,756,263"]
Field Patent Abstract
Required No
Accepted Values String
Example "abstract" : ["PHASE TRANSITION BASED RESISTIVE RANDOM-ACCESS.."]
Field Applications
Required No
Accepted Values String
Example "applications" : [ "applications.."]
Field Benefits
Required No
Accepted Values String
Example "benefits" : ["Advantages of the proposed.."]
Field Short Description
Required No
Accepted Values Long text and summary
Example "body" : ["This invention relates to memory devices, in particular.."]
Field Inventors
Required No
Accepted Values String
Example "inventors" : [ "Joerg Appenzeller"]
Field Inventors Text
Required No
Accepted Values Long text and summary
Example "inventors_text" : ["Joerg Appenzeller, Feng Zhang, Yuqi Zhu, .."]
Field Licensing Availability
Required No
Accepted Values String
Example "licensing_availability" : [ "Exclusive"]
Field Patent Issue Date
Required No
Accepted Values Date
Example "patent_issue_date" : ["2020-08-25"]
Field Patent Status
Required No
Accepted Values String
Example "patent_status" : ["Pending"]
Field Subtitle
Required Yes
Accepted Values String
Example "sub_title" : ["sub title"]
Field Tech Areas
Required No
Accepted Values Array
Example "tech_areas":["Energy, National Security, Biological and Environmental Systems, Environment, Renewable energy technology, Battery Technology, Life sciences, Transportation, Photon Science, High-performance computing, Material Science"]
Field Tech Disciplines
Required No
Accepted Values String
Example "tech_disciplines" : ["Electronics & Hardware"]
Field Technology Type(s)
Required No
Accepted Values String
Example "technology_types" : ["Materials for electronics, Electron Physics, Electronics"]
Field state
Required No
Accepted Values String
+Example "state" : [ "Maryland"]
Field Tech Areas
Required No
Accepted Values String
Example "tech_area" : ["Homeland Security, Dimensional, Information Technology, .."]
Field lab
Required Yes
Accepted Values String
Example "lab" : ["National Institute of Standards and Technology - NIST"]
Field region
Required No
Accepted Values String
Example "region" : ["Mid-Atlantic"]
Field Security Clearance
Required No
Accepted Values Boolean
Example "security_lab" : ["Non Security Lab"]
Field Owner Code
Required No
Accepted Values String
Example "owner_code" : ["Government Owned, Government Operated"]
Field Reps
Required No
Accepted Values String
Example "reps" : ["Joerg Appenzeller, Feng Zhang, Yuqi Zhu, .."]
Field Reference Code
Required No
Accepted Values String
Example "reference_code" : ["reference_code value"]
Field documents
Required No
Accepted Values File
Example "documents" : ["https://federallabs.org/sites/default/files/techs/articles/6096.pdf"]
Field images
Required No
Accepted Values Image
Example "images" : [ "https://18833-flc.pantheonsite.io/sites/default/files/.."]
Field conformsTo
Required No
Accepted Values String
Example "conformsTo" : [ "Not Available"]
Field dataset
Required No
Accepted Values String
Example "dataset" : [ "Not Available"]
Field accessLevel
Required No
Accepted Values String
Example "accessLevel" : [ "Not Available"]
Field bureauCode
Required No
Accepted Values String
Example "bureauCode" : [ "Not Available"]
Field contactPoint
Required No
Accepted Values String
Example "contactPoint" : [ "Not Available"]
Field description
Required No
Accepted Values String
Example "description" : [ "Not Available"]
Field identifier
Required No
Accepted Values String
Example "identifier" : [ "Not Available"]
Field keyword
Required No
Accepted Values String
Example "keyword" : [ "Not Available"]
Field modified
Required No
Accepted Values String
Example "modified" : [ "Not Available"]
Field programCode
Required No
Accepted Values String
Example "programCode" : [ "Not Available"]
Field publisher
Required No
Accepted Values String
Example "publisher" : [ "Not Available"]
Field fn
Required No
Accepted Values String
Example "fn" : [ "Not Available"]
Field name
Required No
Accepted Values String
Example "name" : [ "Not Available"]
 
Field hasEmail
Required No
Accepted Values String
Example "hasEmail" : [ "Not Available"]

Federal Government Fields


USG — Fields specific to the U.S. Federal Government have been denoted with the USG superscript. The Project Open Data schema has been developed as part of a U.S Federal Government open data policy. However, every attempt has been made to align the schema with existing international standards and to provide opportunities for re-use and interoperability with state and local government as well as non-profits, academic institutions, and businesses. There are however some fields that have been introduced specifically for use by the U.S. Federal Government and have special meaning in that context. These fields are: bureauCode, programCode, dataQuality, primaryITInvestmentUII, and systemOfRecords. Non-federal data publishers are encouraged to make use of this schema, but these fields should not be seen as required and may not be relevant for those entities.

Rationale for Metadata Nomenclature

We sought to be platform-independent and to align as much as possible with existing open standards.

To that end, our JSON key names are directly drawn from DCAT, with a few exceptions.

We added the accessLevel field to help easily sort datasets into our three existing categories: public, restricted public, and non-public. This field means an agency can run a basic filter against its enterprise data catalog to generate a public-facing list of datasets that are, or could one day be, made publicly available (or, in the case of restricted data, available under certain conditions). This field also makes it easy for anyone to generate a list of datasets that could be made available but have not yet been released by filtering accessLevel to public and accessURL to blank.

We added the rights field (formerly accessLevelComment) for data stewards to explain how to access restricted public datasets, and for agencies to have a place to record (even if only internally) the reason for not releasing a non-public dataset.

We added the systemOfRecords field for data stewards to optionally link to a relevant System of Records Notice URL. A System of Records is a group of any records under the control of any agency from which information is retrieved by the name of the individual or by some identifying number, symbol, or other identifier assigned to the individual.

We added the bureauCode field to ensure every dataset is connected in a standard way with an agency bureau.

We added the programCode field to ensure that when applicable, every dataset is connected in a standard way with an agency program office.

We added the dataQuality to indicate whether or not the data meets an agency’s Information Quality Guidelines.

Additional Information