The Block Protocol provides a specification for the interaction between web blocks and applications using them: how data structures are typed and passed around, and what data operations are available to blocks.
Its ultimate goal in doing so is to enable any blocks to be usable by any web application without any configuration or human intervention, once both are compliant with the Protocol.
More information on the motivation can be found in the specification overview.
The Block Protocol’s focus is on defining the interface between web blocks and applications using them.
It does not specify what happens to data once it crosses that boundary - it only seeks to standardise application-block interaction.
We do not believe that any existing protocol or specification serves the need of defining the interface between web blocks and embedding applications.
There are efforts which do so for a particular ecosystem (e.g. Microsoft Loop) — but none which improve the web as a whole. The Block Protocol is a generic contract which can be implemented by any web application.
Various frontend libraries and technologies provide means of implementing encapsulated blocks (e.g. React, Web Components) — but they do not standardise the interface between those blocks and the applications using them (e.g. the operations available to them).
Our focus is on supporting the web first and foremost, as this is the context we expect the Block Protocol to be most useful in. Implementation details will vary across contexts — for example, the details of how data can be passed around or operations called — but the general principles of the Block Protocol in defining a contract between applications and embedded blocks are applicable beyond the web. In the future we intend to support non-web contexts more directly.
The goal of the Semantic Web is to make internet data machine-readable.
It involves making sure there is data on web pages which can be parsed by machines, in order to determine the entities described, and their links to other entities elsewhere on the web.
The Block Protocol requires that the data passed between blocks and applications is in the form of entities conforming to a defined structure: a schema.
This structure can then be used to include data on web pages which describes the entities in a machine-readable way.
For example, where a page contains a block displaying a movie, machine-readable data would also be included describing the various properties of the movie (e.g. releaseDate), as well as linking to other pages which describe entities linked to it - e.g. its director.
One way of representing entities in a machine-readable way is in JSON-LD which describes entities and their link to other entities). Here’s an example of such a representation, taken from the JSON-LD homepage:
{
"@context": "https://json-ld.org/contexts/person.jsonld",
"@id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
No, and for the most part the Block Protocol itself does not define the structure of entities passed between blocks and applications. Instead it specifies how entities should be defined, transmitted and updated.
The Block Protocol specifies that JSON Schema should be used to describe the properties of an entity and expected types of property values - not what those properties should be.
You can use existing schema.org schemas, or can create new schemas through the Block Protocol website, once logged in. The schema creator on the Block Protocol website aims to make it easier for users to define the different types of data structures that their blocks will work with.
We don’t prescribe canonical types for any thing, but do recommend that users link their schemas and properties to schema.org types and properties where possible, to help in making the pages that use their schemas machine-readable. We have included a way of doing so in our schema editor. Mapping different schemas and their properties to one another is a process known as ‘crosswalking’.
schema.org defines a collection of schemas for use in making the data on web pages machine-readable.
The Block Protocol does not define the structure of entities passed between blocks and applications - it only specifies how they are transmitted and updated.
Implementers of the Block Protocol could use the structure of entities as defined by schema.org, if they wished (e.g. a block could be built to render or edit a schema.org Event).
We recommend that users link their schemas and their properties to schema.org types and properties where possible, and have included a way of doing so in our schema editor.
You can find all schema.org definitions on the Block Protocol website already, ready to be ‘crosswalked’ back to.
Crosswalked?
Mapping different schemas and their properties to one another is a process known as ‘crosswalking’. It helps machines more easily understand how new schemas fit in to existing knowledge graphs and ontologies.
Schemas are central to our vision for the Block Protocol.
We don’t believe that a single set of schemas provided by any one standards organization (even schema.org) can ever perfectly fit all use cases, and as such the ability to create new schemas is important. When doing this, we want to make them as accessible to machines (and people) as possible.
The Block Protocol website includes a schema editor that provides a convenient way to define new entity types used by or with blocks and their embedding applications. These are then hosted persistently and made accessible via the same content delivery network that serves blocks from the Block Protocol Hub, guaranteeing their availability and discoverability.
Who can see my schemas?
All schemas created on the Block Protocol website are currently public. In future we’ll support the creation of private schemas as well.
schema.org provides a great base ontology for defining lots of types of ‘things’ out there in the world.
givenName and a familyName and yet in various cultures this isn’t guaranteed. HASH uses preferredName and legalName instead - in communications and billing contexts respectively. You can view the HASH ‘Person’ schema at https://blockprotocol.org/@hash/types/Person and see how it crosswalks with the canonical definition of a person provided by Schema.org. This is just one example of how custom schemas can be made to relate back to the core ontology provided by Schema.org.JSON Schema has a rich vocabulary for validating data. We designed the Block Protocol with content management systems and collaborative workspaces in mind, and being able to define precise constraints for data is important for those applications.
We expect to have to add custom keywords to cover relationships which JSON Schema does not have in its core vocabulary (e.g. that a property is inverseOf another), but believe it will be easiest to start with JSON Schema and add keywords, rather than start with another vocabulary and add the required validation to it.
We encourage applications to include JSON-LD describing entities on their public pages to make them machine-readable.
In theory, the Block Protocol could use JSON-LD as the format in which entities are passed between applications and blocks. We did not pursue this because we believe it will be easier and more scalable to handle links between entities outside the JSON for the entity itself, as described here. We have also taken a different approach to identifying entities, which may not have a public URI and may require a combination of fields to identify.
GraphQL provides a “syntax and system for describing [application] data requirements and interactions”, whereas the Block Protocol is specifying a particular set of interactions: those between a block and any application embedding it.
It would be possible to define the operations specified in the Block Protocol in GraphQL - e.g. createEntity - or to extend the GraphQL spec to include them.
We do not yet believe it necessary to specify block-application requests in GraphQL syntax nor require that they be executed by the embedding application according to the GraphQL specification, although we are open to the idea. It may become more attractive as operations evolve to include more features already covered by GraphQL (e.g. subscriptions, selection sets).