Restfulchain is an open source restful blockchain publishing network designed to simplify supply and demand management using semantic web technologies. It offers a robust framework for representing, sharing, and connecting data across various platforms, with a strong focus on Schema.org vocabulary and adherence to GS1 standards. With optional traceability of inputs and certifications, it fosters transparency and precision in global supply chain networks.

Key Features

• RDF Vocabulary Integration: Incorporates established RDF schemas and the Web Ontology Language, with extensions and specializations for supply chain contexts.
• Compatibility with Schema.org: Aligns with Schema.org standards, ensuring broader compatibility and ease of integration with existing web technologies.
• GS1 Standards Compliance: Adheres to GS1 standards, facilitating global supply chain and product information management.

Restfulchain Classes

• RestfulchainSupply: Represents supply-related information, detailing aspects such as product specifications, manufacturing details, certifications, and supply chain inputs.
• RestfulchainDemand: Focuses on demand-side data, encompassing details like requester information, price specifications, minimum production and expiration dates, and demand-related certifications.

Using Restfulchain

1. Setting Up the Context

Begin by defining the @context to include Restfulchain vocabulary alongside other relevant vocabularies like Schema.org and GS1 standards. This context sets the stage for data interoperability and clarity. See the examples provided and follow the nested context as shown.

2. Creating RestfulchainSupply Entries

• Define supply entries with @type: rc1:RestfulchainSupply.
• Include product-related details using GS1 standards, such as GTIN, product name, and manufacturer details.
• Specify version control information and digital signatures through digestValue, dateModifiedTo, etc.

3. Creating RestfulchainDemand Entries

• Define demand entries with @type: rc1:RestfulchainDemand.
• Detail the requester's information, price specifications, and demand validity periods.
• Use GS1 standards for the requested product identification, description, and any requirements.

4. Linking Data

• Utilize @id to uniquely identify each resource within the Restfulchain network.
• Establish provenance using the rc1:input property and when applicable, the rc1:certification property.

5. Geocoding

• All gs1:address objects must be accompanied by gs1:geo within the same parent object.
  • This ensures that geocoding is done once for the benefit of all.

6. Maintaining Data Integrity

• All @id and URLs must use https and must be permalinks.
  • Keep in mind that authorship signing is simply dependent on https.
  • Adopt a versioning schema for your URIs, as each resource's rc1:content is immutable.
• Hashing is used to validate immutability across the chain. 
  • Hashing uses SHA256, base64 encoded, in digestValue and any uriDigestValue.
  • Be certain that rc1:nonce values are globally unique.
• Update and maintain version control data in dateModifiedTo modifiedToURI, and dateDeleted to reflect changes accurately.
  • The updated resource at a new URI must reference the prior version and its hash value with modifiedFromURI and modifiedFromDigestValue.
• The examples provided demonstrate the correct placement of data integrity values; this must be strictly followed.
  • Volatile data, such as gs1:priceSpecification, which may be user-specific or subject to frequent changes, should exist outside of the rc1:content object. This ensures that changing and/or dynamic data does not require distinct versions with distinct values for rc1:digestValue.

7. Webhooks for Push Notifications

• Restfulchain is about publishing data at rest such that it can be crawled and discovered. However, many systems will also require the ability to push notifications of new, modified, or deleted data to notification subscribers.
• When required, Restfulchain solutions should use Standard Webhooks, and be further standardized with the following options:
  • type is limited to: rc1.created, rc1.modified, rc1.deleted.
  • Thin payload only: data.id should be the URI of the Restfulchain record.
    • This URI must be compared against a whitelist, otherwise listeners could be utilized for DDOS attacks.
    • Do not include any of the Restfulchain record data, or else a number of data integrity issues or attacks could occur.
    • Other meta data that is not part of the Restfulchain record data may be added but is considered out of scope of this standard.
  • Symmetric signature scheme
    • This signature must be verified as per the Standard Webhooks documentation before reading the URI from the payload, otherwise notification subscribers could be utilized for DDOS attacks.

8. Managing Private Data

• As much as possible, make data publicly available to increase discoverability of your supply and demand.
• Access to private data when necessary is standardized by using OpenID Connect, which is based on OAuth 2.0.

9. JSON-LD and Content Negotiation

Restfulchain implementations require content negotiation for JSON-LD and HTML responses on the same URI. To receive the JSON-LD data from a URI:

• Set the Accept header to application/ld+json.
• Alternatively, append ?format=ld+json to the URI.
• When HTML is requested, the JSON-LD must be embedded within a script tag with type set to application/ld+json.