updated verification steps
Compare changes
+ 20
− 6
@@ -14,10 +14,10 @@ Certifying that specific data or documents are generated, modified, analyzed, or
@@ -14,10 +14,10 @@ Certifying that specific data or documents are generated, modified, analyzed, or
In addition, as the research process can be considered a workflow - there is a large benefit to include measurements of how data has changed through the research process, for instance between initial acquisition and then preprocessing. Thus, by concatenating multiple generated certificates, the workflow of a research process can be certified and validated at a later point in time.
In addition, as the research process can be considered a workflow - there is a large benefit to include measurements of how data has changed through the research process, for instance between initial acquisition and then preprocessing. Thus, by concatenating multiple generated certificates, the workflow of a research process can be certified and validated at a later point in time.
Our aim is to standardize the research data certification with respect to what metadata should be included to identify the data, the process of research certificate generation, and the subsequent validation of an issued research certificate.
Each certified piece of data is minted as a non-fungible (*Transferable ERC721 compliant or non-transferable) token. Each contract MUST include the ERC721Metadata standard augmented with an additional field that contains the hash of the data object. This is in order to ensure that the dataURI hosted offchain can be resolved to an onchain transaction. The ERC721Metadata is necessary to include the information for future identification of the data object.
Each desired batch of files or singular file is minted as a non-fungible (*Transferable ERC721 compliant or non-transferable) token. Each contract MUST include the ERC721Metadata standard augmented with an additional field that contains the hash of the data object. This is in order to ensure that the dataURI hosted offchain can be resolved to an onchain transaction. The ERC721Metadata is necessary to include the information for future identification of the data object.
@@ -73,8 +73,10 @@ The URI may point to a JSON file that conforms to the EIP-1047 Metadata JSON Sch
@@ -73,8 +73,10 @@ The URI may point to a JSON file that conforms to the EIP-1047 Metadata JSON Sch
"displayHtml": "<h1>bloxberg Certificate</h1><h2>This bloxberg certificate serves as a proof of existence that the data corresponding to the SHA256 Hash were transacted on the bloxberg blockchain at the issued time.</h2>",
// Cryptographic hash that is derived from the research object to certify. The exact hashing algorithm can be generalized, but must uniquely identify a file according to its byte code such as SHA256, SHA-3, or ISCC.
@@ -96,9 +98,21 @@ The research data schema offers flexibility in what specific metadata fields are
@@ -96,9 +98,21 @@ The research data schema offers flexibility in what specific metadata fields are
In addition, due to the algorithmic design of [ISCC](https://iscc.codes/), it is possible to see a similarity matching of how data has been modified during the research workflow.
The hash identifier contained in the metadata extension for a given tokenID must identically match the data object it is referencing. The data object can be either publicly or privately available to concerned parties. Furthermore, by referencing the UNIX time of the block confirmation that included the token mint transaction, a timestamp corresponding to the research object can be verified. The data certificate serves as a user-friendly method to provide evidence of research object certification. The certificate must include the hash code of the data object, an external_url of the data object that corresponds to the hash, and timestamp of the block when the token was minted.