Showing posts with label Semantic. Show all posts
Showing posts with label Semantic. Show all posts

Modeling Semantics: How Data Models and Ontologies Connect to Build Your Semantic Foundations

Mike's Notes

I discovered this reference in the Data Engineering Weekly from Ananth Packkildurai to this great article by Juha Korpela.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

3/02/2026

Modeling Semantics: How Data Models and Ontologies Connect to Build Your Semantic Foundations

By: Juha Korpela
Modern Data 101 (Medium): 22/01/2026

Independent Consultant | Data Modelling Enthusiast | Founder @ Helsinki Data Week.

This piece is a community contribution from Juha Korpela, Independent Consultant and Founder of Helsinki Data Week, a community-first data conference. With deep expertise in information architecture, data products, and modern operating models, Juha has spent his career helping organisations truly understand what their data means and how to use that semantic clarity to build better systems.

Formerly Chief Product Officer at Ellie Technologies and now the voice behind the “Common Sense Data” Substack, Juha is also a speaker, trainer, and advisor shaping the resurgence of conceptual modeling in the industry. We’re thrilled to feature his unique insights on Modern Data 101!

We actively collaborate with data experts to bring the best resources to a 15,000+ strong community of data leaders and practitioners. If you have something to share, reach out!

Share your ideas and work: community@moderndata101.com

  • Note: Opinions expressed in contributions are not our own and are only curated by us for broader access and discussion. All submissions are vetted for quality & relevance. We keep it information-first and do not support any promotions, paid or otherwise!

Let’s Dive In!

Knowledge Management Provides Context for AI

Knowledge Management and Information Architecture have had a rocket ride to the top of the data world’s consciousness due to Generative AI. The ability to organize, store, and serve structured semantics as context to various agents and chatbots is widely recognized as a winning ingredient in the GenAI race, reducing hallucinations and improving accuracy.

Terms like taxonomies, ontologies, and knowledge graphs are being thrown around as if just been invented, but veterans of the trade know better: there’s nothing new under the sun.

Knowledge Management and the Library Sciences, from which these subjects were born, are well-known disciplines, and the theory behind concepts like the Semantic Web is solid. It’s merely the utilization of these that has now changed with GenAI.

Data Modeling Foundations Return

But when it comes to organizing, storing, and serving semantics, there have always been two schools of thought, usually with very little cross-pollination between them. The other viewpoints outside ontologies and knowledge graphs have been coming from the data modeling world.

Traditionally, data modeling has had different levels of abstraction to cover different needs at different levels of detail. Conceptual, Logical, and Physical modeling has been a well-recognized three-level layout for data modeling activities (you can check my views on these three levels on my Substack).

But sadly, at some point in the Big Data craze of yesteryear, many data experts reduced data modeling to the Physical level only, focusing almost exclusively on the technical structures of data storage.

Where Semantics Was Compromised

By forgoing Conceptual modelling to a large extent, data experts had let go of a very practical method for doing exactly the same thing that is now required from taxonomies, ontologies, and knowledge graphs: describing structured semantics.

At the core of both ontologies and conceptual data models are things: real-life entities that exist in the real business, irrespective of the systems we have built. You might call these things “entities” or “objects” or “nodes” or whatever you like,

…but they are what you need to understand in order to describe

(to a human or an agent) what goes on in your business.

Think of “Customer”, “Order”, “Product”, “Delivery”, and so on. These are what you have data about, no matter how the data is technically stored in database tables or files.

In addition to the list of things, to fully understand the business context, we need relationships between the things. How do the things in our business interact with each other? Think “Customer makes an Order”, “Product is added to Delivery”, and so on.

Ontology vs. Conceptual Model

An ontology is, in simple terms, a list of things (and their definitions) with a list of the relationships between them. In the Knowledge Management world, this would be formalized according to, say, RDF standards.

A conceptual model is, in simple terms, also a list of things and their relationships. Data modelers traditionally produce an Entity-Relationship Diagram out of it, with a list of entity definitions (a Glossary) attached.

Now here’s the important thing to understand, regardless of which world you are coming from:

the semantical content you capture with both approaches is exactly the same!

Merely the method of capturing, organizing, and storing that information is different.

For me personally, the method of conceptual modeling feels natural, as I’ve done data modeling for around 15 years now. I know what questions I need to ask people (or what documents to read) to capture information about the entities and their relationships, I know how to draw the diagram, I know how to create the glossary, and I know what tools I can use to help.

For someone coming from a semantic web background, building formalized ontologies according to the RDF standard feels natural, with all the methods and tools that come with it.

We’re both still working on semantics: in effect, we’re capturing the exact same ontology, thus storing information about business context to be used later.

Technical Implementation of Semantics

For us data modelers, the utilization of these models has traditionally focused on the technical implementation of data solutions, and we’ve thus followed a path from Conceptual to Logical to Physical. That is, if we have done conceptual modeling at all!

But especially now, in the age of context-hungry AI, we have to realize we’ve been sitting on a semantics gold mine: conceptual data modeling is an excellent method for figuring out what the entities and relationships should be.

The diagram titled “How Data Models & Ontologies Connect to Build Semantic Foundations” shows “Understanding the business” leading into “Conceptual Modeling,” which branches into two paths: “Solution Design” and “Semantic Discovery”. The ontology also integrates inputs from Standard Ontologies and AI Agents.

How Data Models and Ontologies Connect to Build Semantic Foundations | Source: Author

Why is this important? Because the most valuable semantical information is that which is unique to the organization, and those semantics are the hardest to capture.

While AI tools can be used to find semantical concepts from unstructured data and various knowledge bases, a lot of this information is tacit knowledge in the business experts’ heads. Conceptual modeling is a known-good method for getting that tacit knowledge out.

Data Modeling as Semantic Discovery

I envision a world where we build the semantic foundation of an organization with a set of tools at our disposal:

A pyramid diagram titled “Building Organisational Semantics” illustrating the layers of a Semantic Foundation. The foundation acts as a context provider for both agents and humans. It features three tiers: Industry Standards at the base for common structures, Conceptual Modeling in the center to unearth unique organisational knowledge, and AI Agents at the apex to find details that enhance core semantics.

Technical Implementation of the semantic Foundation with Industry Standards, Conceptual Modeling, and AI Agents | Insights from the Author

  • We use industry standards and existing knowledge bases to cover the basic structures that are common to most organizations within an industry
  • We use conceptual modeling methods as a surgical knife to cut through tacit knowledge and unearth & document the valuable, unique semantics of the organization
  • We use AI agents as “semantic helpers” to trawl through tons of documentation and find details to add around the strong core that has been formed

This semantic foundation will then act as the context provider for all your agents and chatbots, but also for humans! Context is king in today’s world. By looking at data modeling as not only a technical design method, but as a semantic discovery method, we enable a powerful tool for building this context.

By , No comments:
Tags , , ,

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

Mike's Notes

I like the specification and hope to enable its use via a future Pipi plugin. Here is an article by Ananth Packkildurai about some flaws that need fixing. His weekly newsletter is worth subscribing to.

Resources

References

  • Iceberg REST Catalog Specification.
  • Designing Data-Intensive Applications, by Martin Kleppmann.

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Data Engineering Weekly
  • Home > Handbook > 

Last Updated

19/01/2026

A Critique of Iceberg REST Catalog: A Classic Case of Why Semantic Spec Fails

By: Ananth Packkildurai
Data Engineering Weekly: 9/01/2026

Ananth Packkildurai is a data engineering leader, writer, and author of Data Engineering Weekly, sharing insights on modern data platforms, large-scale pipelines, and AI-driven architectures..

How a Semantically Correct API Becomes Operationally Unreliable at Scale.

“Latency is not just a performance characteristic; it is a fundamental part of correctness.” — Designing Data-Intensive Applications

In Designing Data-Intensive Applications, Martin Kleppmann makes a subtle but critical point: the CAP theorem omits latency, yet in real systems, latency often determines whether a system is usable at all. A system that is correct but slow is, in practice, incorrect.

This observation is directly applicable to the Apache Iceberg REST Catalog specification. While the specification achieves semantic clarity, it fails to define the operational realities that enable distributed systems to remain predictable at scale. The result is a standard that is formally correct, yet operationally fragile.

Semantic Interoperability Without Predictability

Over the past two years, the Iceberg REST Catalog specification has emerged as the de facto standard for metadata access in the Iceberg ecosystem. We have seen the outburst of the catalog war around the REST spec. It promises a universal interface that allows engines such as Trino, Spark, Flink, and StarRocks to interact with Iceberg tables via a common REST abstraction, independent of the underlying catalog implementation.

At the semantic level, this promise largely holds. The specification rigorously defines metadata structures: tables, schemas, snapshots, and namespace operations. A LoadTable or CreateNamespace request looks identical across implementations. This semantic interoperability has been critical to Iceberg’s rapid ecosystem adoption.

However, semantic interoperability alone is insufficient. The specification defines what metadata operations mean, but it avoids specifying how they must behave in real-world conditions, such as concurrency, latency sensitivity, and cross-catalog synchronization.

This gap—between semantic interoperability and operational interoperability—is where systems begin to fail in production.

The Core Problem: No Operational SLA, No Predictability

The Iceberg REST Catalog specification is intentionally silent on performance guarantees. There are no latency expectations, no throughput baselines, and no service-level objectives. While this flexibility lowers the barrier to implementation, it creates an ecosystem where:

  • Two catalogs can both be “compliant” yet differ by orders of magnitude in response time.
  • Clients cannot reason about metadata latency during query planning.
  • Synchronization behavior across catalogs becomes unpredictable.

In distributed data systems, predictability matters more than raw performance. Without a strict operational SLA—or at least defined behavioral constraints—clients are forced into defensive, retry-heavy designs that amplify load and increase tail latency.

The “List Tables” Problem: Cross-Catalog Sync Failure

The ListTables endpoint (GET /v1/namespaces/{namespace}/tables) is semantically straightforward. It allows clients to enumerate tables within a namespace and supports pagination through pageSize and pageToken.

The primary issue is not pagination itself. The real failure emerges when the same Iceberg tables are registered in multiple catalogs, a pattern that is increasingly common in hybrid and multi-platform deployments.

A Realistic Scenario

  • An Iceberg table is registered in Catalog A and Catalog B
  • Both catalogs point to the same underlying metadata and object storage.
  • One catalog is used by ingestion and streaming workloads.
  • Analytics engines or BI tools use the other.

The Sync Pathology

When a client connects to Catalog B and issues a metadata discovery operation—such as listing tables or syncing namespace state—the catalog must:

  1. Enumerate all tables
  2. Resolve metadata pointers
  3. Validate access permissions
  4. Reconcile the state with the underlying storage.

Because the REST specification defines no operational expectations:

  • There is no SLA for how long this sync should take
  • There is no distinction between a “lightweight” listing and a fully validated listing.
  • There is no mechanism to express intent (e.g., names only, no ACL validation)

As table counts grow into the tens of thousands, synchronization latency grows non-linearly. In practice, sync operations can take minutes—or fail—causing engines to stall, time out, or repeatedly retry.

The result is not merely slow metadata access. It is system-wide unpredictability. Query engines cannot determine whether a delay is transient, systemic, or catastrophic.

Latency Is Treated as an Implementation Detail—But It Is a Contract

The REST Catalog specification implicitly treats latency as an implementation concern. From a standards perspective, this is understandable. But in data-intensive systems, latency is part of the correctness contract.

The specification does not define:

  • Upper bounds on metadata retrieval latency
  • Maximum metadata payload sizes
  • Limits on metadata fan-out operations
  • The number of round-trip required to plan a query

As a result, a compliant catalog may require megabytes of JSON metadata and dozens of HTTP calls just to validate a single query plan. Engines appear slow and unstable, even though the root cause lies in an underspecified protocol.

This is precisely the class of problem Kleppmann warns about: correctness without latency guarantees is operationally meaningless.

Commit Semantics Under Contention: Undefined and Unfair

Iceberg relies on optimistic concurrency control. When multiple writers attempt to commit simultaneously, conflicts are expected and resolved through retries.

The REST specification defines the 409 Conflict response, but stops there. It does not define:

  • Backoff expectations
  • Retry fairness
  • Starvation prevention

In a multi-engine environment, this creates asymmetric outcomes. A high-frequency streaming writer with aggressive retries can permanently starve batch compaction jobs that follow conservative retry policies. Over time, table health degrades due to file explosion and unbounded metadata growth.

Once again, the issue is not semantic correctness. It is the absence of operational guarantees.

Caching Without a Freshness Model

While HTTP caching is permitted, it is not part of the correctness model. Support for conditional requests, ETags, or freshness validation is optional.

This forces clients into a pessimistic stance: always re-fetch, always revalidate, always assume staleness. The REST protocol degenerates into a chatty, high-latency control plane that negates its own architectural benefits.

Without a standardized freshness contract, caching becomes a gamble rather than a reliability tool.

Behavioral Conformance Is Missing

The Iceberg ecosystem has strong conformance testing for table formats. It lacks an equivalent for catalog behavior.

Today, “REST Catalog compliant” means:

  • The endpoints exist
  • The JSON schema is correct.
  • The happy path works.

It does not mean:

  • Predictable latency under load
  • Stable pagination during concurrent updates
  • Graceful overload signaling
  • Bounded retry amplification

Without behavioral conformance tests, compliance guarantees syntax, not operability.

Underspecification Is Still a Design Decision

The absence of operational constraints is not accidental. It reflects a deliberate choice to prioritize adoption and flexibility.

However, in distributed systems, underspecification pushes complexity downstream. It burdens clients, operators, and platform teams with the need to implement compensating logic. As Iceberg becomes core infrastructure rather than experimental tooling, this trade-off increasingly limits its reliability.

Semantic agreement without behavioral agreement leads to fragile systems.

Toward Operational Interoperability

Operational interoperability does not require rigid SLAs or centralized control. It requires acknowledging that latency, retries, and fairness are part of the interface.

Concrete improvements could include:

  • Defined operational profiles with minimum latency and concurrency expectations
  • Lightweight metadata views to avoid synchronization amplification
  • Standardized retry and backoff semantics for conflict scenarios
  • Explicit freshness and caching contracts

Semantic interoperability enabled Iceberg’s success. Operational interoperability will determine whether it remains dependable at scale.

Until then, the Iceberg REST Catalog remains a textbook example of why semantic specifications alone are not enough.

By , No comments:
Tags , , ,

Pipi 9.1.0

Mike's Notes

Pipi self-versioning has resumed after being frozen since 2020. Previously, Pipi was versioned whenever developers logged changes.

Resources 

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

10/01/2026

Pipi 9.1.0

By: Mike Peters
On a Sandy Beach: 9/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Automated Pipi semantic versioning has restarted. The previous version was frozen at Pipi 9.0.2+398; the current version is Pipi 9.1.0+399.

The next minor version change occurs on Friday, 10 April 2026, at 8am.

Build

  • Every change to a namespaced object increments the Build Number by 1
  • It is the internal system change ID
  • Daily Builds could vary from 0 to 1,000s
  • Never resets.

Patch

  • Release daily if there have been Build Number increases
  • Numbered 0-999
  • Resets when a Minor Release occurs
  • Minor documentation edits

Minor Release

  • Release 4x per year, 3 months apart on the 2nd Friday at 8am, NZ Time.
  • Numbered 0-99
  • Resets when a Major Release occurs
  • Documentation officially updated

Major Release

  • Release when a Minor Release backwards-incompatible change occurs, on the 2nd Friday of January, April, July or October.
  • Usually every 2-3 years
  • Numbered 1-99
  • New documentation released
  • Account migration required

Notes

Minor releases account for emergent behaviour changes in the system as a whole; the date is arbitrary. Major Releases account for phase-level changes when they occur.

It will take a while to get everything running according to plan. It requires enabling extensive automation across multiple systems. As a result, some parts will initially be out of sync.

If the Version Engine (ver) had been running since 2000, the number of changes would make the current Pipi version look something like

  • Pipi 9.18.78+25,000-beta

Rendered HTML

Rendered: 08:41 UTC, 9 January 2026 by Pipi 9.1.0+399-beta

By , No comments:
Tags , , ,

Knowledge Graphs Should Not Be Just for Analytics and Insights

Mike's Notes

Good words from John Gorman in Canada.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

04/12/2025

Knowledge Graphs Should Not Be Just for Analytics and Insights

By: John Gorman
LinkedIn: 06/11/2025

Information management professional specializing in semantic interoperability, with over 30 years of experience. Principal, Founder and Chief Disambiguation Officer at Quantum Semantics Inc in Calgary. Inventor of the Q6 information management model.

There is, in my view, a large and currently under-served audience for knowledge graphs in the enterprise. These are employees, contractors, and yes, even executives who need access to a more granular level of access to company knowledge.

Maybe we should start calling them 'Learning Graphs' instead.

The interesting thing is, by providing this level of service, solutions to other gnarly challenges like data governance, metadata, reference and master data management, data fluency, semantic interoperability, and when done properly (i.e. FAIR-From-Birth) dimensional analysis of operational data stores, make themselves available.

Sounds ambitious? Why not? Enterprise Information is now all about language, so how about we start there and leverage persistent patterns of classification and usage. Here are some of the immediate and 'downstream' benefits:

  • Data Governance. Most companies make the mistake of starting with data. The more natural approach - and with a lot less risk to life and limb - is to begin with the language of the business. And, you get to roll out a 'FAIR-From-Birth' business glossary as a side benefit, just like the big boys and girls.
  • Metadata. Business users rarely even care about metadata, but when they see how the language of the business connects to and is equivalent to metadata values the light bulbs start to go on. As a bonus, they also get to see how missing, misspelled, and misshapen vocabulary gums things up.
  • Reference and Master Data. This is another opportunity to see how the information supply chain should work. Crap components upstream means crap assemblies downstream. Ask your local supermarket manager how he handles a shipment of rotting tomatoes. 

The benefit for business owners is two-fold:

  1. They get to see what kind of cleanup is required when they throw crap over the fence.
  2. They also get to see how one-and-done actually reduces their workload.

Data Fluency. Seeing the connections between how they talk about the business and what kinds of data those conversations connect to? Priceless.

Semantic Interoperability. Ah, yes... the Holy Grail. What if we made it possible to access semantically equivalent pairs as a start? So, if Jane McCallum, the CFO of Acme Inc. doesn't know (have knowledge of) the meaning of the acronym FLOC, she can simply look it up on her phone during her Monday executive team meeting and learn it. No embarrassing interruptions, just immediate access to enterprise knowledge. What a concept!

Analytics and Insight. Finally, the raison d'être for almost every technical innovation so far this decade. When an information supply chain starts with the notion that every component, especially the very granular ones, should be engineered to fit into a downstream, multi-dimensional ecosystem of semantically connected information good things start to happen. 

DM me if you want to learn more about Semantium's set of protocols.

By , No comments:
Tags , ,

Progress on the block protocol

Mike's Notes

Joel Spolsky has some ideas about the semantic web.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

18/05/2025

Progress on the block protocol

By: Joel Spolsky
Joel on Software: 19/02/2002

Since the 1990s, the web has been a publishing place for human-readable documents.

Documents published on the web are in HTML. HTML has a little bit of structure, for example, “here is a paragraph” or “emphasize this word.”

Then you stir in some CSS, which adds some pretty decorations to the structure, saying things like: make those paragraphs have tiny gray sans-serif text! And then people think you are hip. Unless they are older, and they can’t read your tiny gray words, so they give up on you. That’s “structure,” as far as it goes, on the web.

Imagine, for example, that you mention a book on the web.

Goodnight Moon
by Margaret Wise Brown
Illustrated by Clement Hurd
Harper & Brothers, 1947
ISBN 0-06-443017-0

There’s not much structure there. A naive computer program reading this web page might not realize I was even mentioning a book. All I did was make the title bold.

So, also since the 1990s, people have realized that we can make the web a much more useful place to publish information if we applied a bit more structure. As early as 1999, Tim Berners-Lee was writing about the Semantic Web:

“I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which makes this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize.” - Tim Berners-Lee, Weaving The Web, 1999 HarperSanFrancisco (Chapter 12)

Using the Semantic Web you might publish a book title with a lot more detail that makes it computer-readable. To do this, you would probably start by going to schema.org and looking up their idea of a book. Then you could use one of a number of formats, like RDF or JSON-LD, to add additional markup to your HTML saying “hey! here’s a book!”

Ok, well, doing that is kinda hard to figure out, and, to be honest, it’s homework. Once your beautiful blog post is published and human-readable, it’s hard to gather the mental energy to figure out how to add the additional fancy markups that will make your web page computer-readable, and, unless there is already a computer reading your web pages, at this point, you usually give up. So, yeah. That was 1999, and not much progress has been made and there is very little of this semantic markup in the wild.

Well.

We would like to fix this, because human progress depends on getting more and more information in formats that are readily accessible, both by regular humans, their dumb A.I. li’l sibs, and your more traditional computer programs.

Here is something I believe: people will only add semantic markup to their web pages if doing so is easier than not.

In other words, the cost of adding semantic markup has to be zero or negative, or this whole project is not going anywhere.

Now imagine this world for a second:

I want to insert a book into my blog post

  • I type /book
  • A search box appears where I start typing in the title of my book and choose from an autocomplete list.
  • Once I find the book, a block gets inserted in my blog post showing details of the book in a format I like, with nice semantic markup behind the scenes.
  • In this world I did less work to insert a book (because I was assisted by a UI that looked up the details for me).

You can imagine the same scenario applying to literally any other kind of structured data.

I want to insert an address into my blog post

  • I type /address
  • A search box appears where I start to type a location, which autocompletes in the way you have seen Instagram and Google Maps and a million other apps do it
  • Once I choose the address, a block gets inserted showing the details of the address complete with semantic markup behind the scenes.
My “address block” might have any visual appearance. Visitors to my web page might see the address, or a little map, or a little map in Japanese, etc. etc. The semantic content is there behind the scenes. So, for example, my web browser might know “gosh this is an address!

Maybe you want to do address-y things with it, like go there,” and then my browser might offer me options to summon a self-driving car and even call an ambulance when the self-driving car self-drives into a snowbank.

My two simplistic examples of “book” and “address” are interesting right now because (a) you can probably think of 1,000,000 more data types like this, and (b) none of these things work right now, because even though almost every web editing environment has a concept of “blocks,” none of them are extensible. WordPress has (oh gosh) hundreds of block types, but they don’t have thousands or millions, they don’t have “book” or “address” or “Burning Man Theme Camp” yet, and there’s no ecosystem by which developers and users can contribute new block types.

So I guess I gotta wait around for someone at WordPress to develop all the blocks I want to use. And then someone at Notion, and then someone at Trello, and then someone at Mailchimp, and someone at every other vendor that provides a text editor.

I have a better plan.

The web was built with open protocols. Suppose we all agree on a protocol for blocks.

Any developer that wants to create a new block can conform to this protocol.

Any kind of web-text-editing application can also conform to this protocol.

Then if anyone goes to the trouble of creating a cool “book” or “address” block, we’ll all be able to use it, anywhere.

And we shall dub this protocol, oh I don’t know, the Block Protocol.
And it should be, I think, 100% free, open, and public, so that there is no impediment to anyone on earth using it. And in fact if you want to make blocks that are open source or public, good for you, but if for some reason you would like to make private or commercial blocks, that’s fine too.

Where we’re up to

It’s been about a year since we started talking about the Block Protocol, and we’ve made a lot of progress figuring out how it has to work to do all the things it will need to do, in a clean and straightforward way.

But this is all going nowhere if it requires 93,000,000 humans to cooperate with my crazy scheme just to get it off the ground.

So what we did is build a WordPress Plugin that allows you to embed Block Protocol blocks into posts on your WordPress sites just as easily as you insert any other block.

Since WordPress powers 43% of the web, that means if you build a block for the Block Protocol, it’ll be widely usable right away.
Here’s a video demo:

The WordPress Plugin will be free, and it will be widely available in February, when we’ll also publish version 0.3 of the Block Protocol specification. You can get early access now.

In fact, if you were thinking of writing a plugin for WordPress for your own kind of custom block, you’ll find that using our plugin as your starting point is a lot easier, because you don’t have to know anything about WordPress Plugins or write any PHP code. So even if you don’t care for any of my crazy theories and just want to add a block to WordPress, this is the way to go.

Ultimately, though, we just want to make it easier to add useful semantic, structured information to the web, and this is the first step.

PS We just set up a Discord server for the Block Protocol where you can participate, ask questions, and meet the team.

By , No comments:
Tags ,
Subscribe to: Posts (Atom)