Data Mesh and Data Fabric

[Michael DeBellis]

I'm wondering if anyone has opinions on Data Mesh and Data Fabric definitions? When I talk to practitioners most people say that the major difference is Data Fabric is about centralized data governance but Data Mesh is about federated governance. Essentially Data Mesh is trying to apply the Microservices model to data rather than process. That last part I think is correct but not the first part. When I read things by Gartner, Dehgani's Data Mesh book, etc. it seems to me that:

1) Data Fabric isn't an architecture. It is a set of aspirations. Features such as "active metadata" and "governance as code" that Gartner thinks all Enterprise Data architectures should aspire to. But they don't give many specifics about how to implement architectures that achieve those goals. 

2) Data Mesh doesn't actually advocate for completely federated governance. Dehgani says that in her book. She says it a bit differently something like "I've never seen a customer with a pure Data Mesh architecture and probably never will" (that's a paraphrase, not an actual quote). IMO the difference on centralized vs. federated governance is a continuum not an either/or. The early adopters like Amazon, Linked In, Reddit, Google, will be more toward the federated model and the industries like Healthcare that are risk and technology averse will mostly or completely use a centralized governance model. 

3) So I think the main difference is that Data Fabric defines a set of goals and Data Mesh describes an architecture (Kafka, Docker, Kubernetes) or more generally (Events, Containers and Orchestration) that people like Dehgani think is the best way to achieve  the goals of Data Fabric. 

Just wondering if anyone else has opinions. BTW, the reason I think this matters is that Semantic Web technology is such a clearly excellent fit to achieve the goals of a Data Fabric and to implement a Data Mesh. 

Michael

https://www.michaeldebellis.com/blog

[Mark Underwood]

Michael,

When I looked at this, I thought it was a promising approach -- either fabric or mesh.  But after having seen how these are built and managed, and considering the lack of standards around either, I find the service mesh approach more compelling; see NIST 800-233.

Looking at "data" without its orchestrating tooling and dependencies is a bridge too far, even for limited, domain-specific use cases.  

Which is not to say you can't push all the data you have at the LLM and ask it to make sense of it - schemas, raw code, dictionaries, metadata registries -- because it will help you.

From a pragmatic, consultative point of view, enterprises need to manage ("federate" in a general sense) across multiple abstraction layers. I imagine you can get there through multiple techniques, but as you decompose from the "Business" Capability Models (or "Mission" in the defense sector), there are several useful layers before you get to "data."

At the moment I can't recall the name of the firm whose approach most impressed me.  I'll send it later if I remember it.

You might also want to follow the observability space.  E.g.See this:

...

Also FYI https://www.dtaalliance.org/ 

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/71409b9d-2974-4ee5-97b1-d54609d2b917n%40googlegroups.com.

--

Mark Underwood 
Linkedin  

[John F Sowa]

Michael,

i'm skeptical about that distinction of data fabric/mesh. It seems like a distinction that is tied to a specific design strategy  for somebody's software tools. 

It may be useful for software developed with those tools.  But it doesn't sound like a universal principle that would apply to any kind of software developed for any kind of project for any kind of purpose.

I would not recommend it as a general principle for ontology.

John

 

---

From: "Michael DeBellis" <mdebe...@gmail.com>

[Michael DeBellis]

Thanks Mark. I'm focusing more on the business world than Defense. Defense is IMO kind of like Healthcare, a very specialized case where the normal rules don't apply. I'm most interested in Internet companies like Amazon, Linked In, Reddit, etc. They tend to lead the way in adopting new ideas. BTW, I agree that LLMs are going to play a big role in all of this. Last year I was reading a book on Data Catalogs and I got to the chapter on Search and thought "well, may as well skip it" because it was written before LLMs took off so IMO it was almost irrelevant. I'm exaggerating to make a point of course but not that much. Thanks for the info.

Michael

https://www.michaeldebellis.com/blog

You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/G_uFi5YrCug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAPE7sbyWjGQYMPZC5i0QuFPAB4%3Dehjjf2UMRrrEgOySW%2BSA6ng%40mail.gmail.com.

[Ravi Sharma]

All including Micheal DeBellis

• Federated is where different stakeholders can interoperate in an enterprise Architecture (we are addressing a smaller part relating to data). Their identities, permissions allow them to subset automatically to their permitted areas written in security and business rules / books. Hence vocabularies and semantics and therefore ontologies are relevant.
• Central is where a single controlling authority for validation before interoperation is implied. (rare example, such as Master Data Management). In supply chain one wy management where suppliers can see demand by consolidation of enterprises requirements this is implied as only materials Requirements Planning and execution data are accessible but not manufacturing!

I have not factored LLMs and AI in my comments.

Regards.

Thanks.

Ravi

(Dr. Ravi Sharma, Ph.D. USA)

NASA Apollo Achievement Award

Former Scientific Secretary iSRO HQ

Ontolog Board of Trustees

Particle and Space Physics

Senior Enterprise Architect

SAE Fuel Cell Standards Member

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFikcDQErko0NSTZt7gKePC%3DsNvRiVxDfYAicdcvmxzk%3DNcQ%40mail.gmail.com.

[Simon Polovina]

Hi Michael.

My recent paper on Enterprise Architecture touched on metadata analytics, where data is the first-class citizen rather than applications. It may bear on your query. I'm unsure I'd call it ontology, but I hope it helps.

Here's the paper: Moregraph: Metadata-Driven Enterprise Architecture Using Conceptual Structures.

Simon

Dr Simon Polovina

Simile Logics Limited

Profile │ Email

 

---

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> on behalf of Michael DeBellis <mdebe...@gmail.com>
Sent: Wednesday, January 28, 2026 01:46
To: ontolog-forum <ontolo...@googlegroups.com>
Subject: [ontolog-forum] Data Mesh and Data Fabric

[Alex Shkotin]

Michael,

I like this answer from AI https://claude.ai/share/6599b2e0-fb0d-4521-bd89-b8cc6cf02063

What do you think?

Alex

ср, 28 янв. 2026 г. в 04:47, Michael DeBellis <mdebe...@gmail.com>:

--

[Ravi Sharma]

Alex 

It merely repeated what the thread contains, no specific analysis?

Regards

Thanks.

Ravi

(Dr. Ravi Sharma, Ph.D. USA)

NASA Apollo Achievement Award

Former Scientific Secretary iSRO HQ

Ontolog Board of Trustees

Particle and Space Physics

Senior Enterprise Architect

SAE Fuel Cell Standards Member

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAFxxRORjsbCyvo1XiCZkgFj_09mFyTSCQ_VfjjPrsGC4k7buMw%40mail.gmail.com.

[Simon Polovina]

Alex, that answer resonates with my earlier response 👍🏼

Michael, Data Mesh: Delivering Data-Driven Value at Scale by Zhamak Dehghani (O’Reilly) may also be of interest.

Simon

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Alex Shkotin
Sent: 28 January 2026 09:46
To: ontolo...@googlegroups.com
Subject: Re: [ontolog-forum] Data Mesh and Data Fabric

 

Michael,

 

I like this answer from AI https://claude.ai/share/6599b2e0-fb0d-4521-bd89-b8cc6cf02063

What do you think?

 

Alex

 

ср, 28 янв. 2026 г. в 04:47, Michael DeBellis <mdebe...@gmail.com>:

I'm wondering if anyone has opinions on Data Mesh and Data Fabric definitions? When I talk to practitioners most people say that the major difference is Data Fabric is about centralized data governance but Data Mesh is about federated governance. Essentially Data Mesh is trying to apply the Microservices model to data rather than process. That last part I think is correct but not the first part. When I read things by Gartner, Dehgani's Data Mesh book, etc. it seems to me that:

 

1) Data Fabric isn't an architecture. It is a set of aspirations. Features such as "active metadata" and "governance as code" that Gartner thinks all Enterprise Data architectures should aspire to. But they don't give many specifics about how to implement architectures that achieve those goals. 

 

2) Data Mesh doesn't actually advocate for completely federated governance. Dehgani says that in her book. She says it a bit differently something like "I've never seen a customer with a pure Data Mesh architecture and probably never will" (that's a paraphrase, not an actual quote). IMO the difference on centralized vs. federated governance is a continuum not an either/or. The early adopters like Amazon, Linked In, Reddit, Google, will be more toward the federated model and the industries like Healthcare that are risk and technology averse will mostly or completely use a centralized governance model. 

 

3) So I think the main difference is that Data Fabric defines a set of goals and Data Mesh describes an architecture (Kafka, Docker, Kubernetes) or more generally (Events, Containers and Orchestration) that people like Dehgani think is the best way to achieve  the goals of Data Fabric. 

 

Just wondering if anyone else has opinions. BTW, the reason I think this matters is that Semantic Web technology is such a clearly excellent fit to achieve the goals of a Data Fabric and to implement a Data Mesh. 

 

Michael

https://www.michaeldebellis.com/blog

.

[Simon Polovina]

Agreed, Ravi, though it helps with summarising the topic 🤔

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Ravi Sharma

Sent: 28 January 2026 10:06
To: ontolo...@googlegroups.com

[Alex Shkotin]

Ravi

Michael asked for opinions. I sent him the opinion of Claude. 

Regards

Alex

ср, 28 янв. 2026 г. в 13:06, Ravi Sharma <drravi...@gmail.com>:

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAAN3-5cQte_pHLFt0Wv3Zfcx-ozw314En9V3JbpQV69TdCdMXA%40mail.gmail.com.

[Alex Shkotin]

Simon, super!🤝

Alex

ср, 28 янв. 2026 г. в 13:09, Simon Polovina <si...@similelogics.ltd>:

--

All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/LOAP123MB835295C8C54CF2ED8C21552DD491A%40LOAP123MB8352.GBRP123.PROD.OUTLOOK.COM.

[Burkett, William [USA]]

Michael –

 

A snarky response is:

 

1. Data mesh is object-oriented programming reimagined at an enterprise scale
2. Data fabric is a decorative marketing term devised to connote “weaving together” of many systems and has no reasoned engineering substance to it.  I see it as no different than “systems integration” with a little more attention paid to data architecture.

 

Disclaimer: My snark on data mesh is more informed than that on data fabric. 

 

Bill Burkett

--

All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/71409b9d-2974-4ee5-97b1-d54609d2b917n%40googlegroups.com.

[Michael DeBellis]

Yes, thanks that is actually extremely relevant to what I'm working on. Thanks for the link. 

You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/G_uFi5YrCug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/LOAP123MB83521348A2666B7EFE0653CCD491A%40LOAP123MB8352.GBRP123.PROD.OUTLOOK.COM.

[Michael DeBellis]

Alex, that is a good summary of what I consider the "common wisdom" that I hear from practitioners and I've seen in various articles. I can understand how an LLM would come up with that because most of the data its been trained on includes that point of view. But as I looked at both more carefully, I think there is a bit more to it and as I said IMO the best way to look at it is Data Fabric defines goals and Data Mesh defines an architecture to achieve those goals. Some specific replies: 

"Data Mesh... includes... Domain-oriented decentralization: Data ownership and pipelines are distributed across different business domains rather than centralized in a single data team" IMO that isn't completely accurate. Data Mesh attempts to make data governance and development more distributed but Dehgani (the woman at Thoughtworks who popularized the term) says in her book that there will always be some need for centralized data governance as well. E.g., if you are a healthcare company you aren't going to let each different business unit figure out how to comply with HIPAA, your going to centralize it. If you are an Internet company you aren't going to allow each business unit to figure out how to comply with the European Union's General Data Protection Regulation (GDPR). That would be insane. For example, part of the GDPR is the "right to be forgotten" that is something that almost has to be centralized in order to be sure you can delete all info related to a user if they request. 

"Data Mesh... includes... Data as a product: Each domain treats their data as a product with clear ownership, quality standards, and consumers in mind" Data Products are not unique to Data Mesh. I think the idea started there but it is now being embraced by people who don't believe in Data Mesh. There is a good book by a guy named Strengholt called something like Data Management at Scale. He is very skeptical of Data Mesh but he talks a lot about Data Products. Almost half of his book is about how to build and use data products.

"Data Mesh... includes... Self-serve data infrastructure: A platform that enables domain teams to create and manage their own data products without needing specialized technical expertise" Same reply. "Self-serve infrastructure" IMO is essentially the same idea as "policy as code" and "active metadata", two ideas that are at the core of the way Gartner describes Data Fabrics. 

Data Fabric... includes... Centralized orchestration: Unlike Data Mesh's decentralization, Data Fabric typically uses centralized tools and automation" The most popular tool (Data Mesh or Fabric) for Orchestration right now is Kubernetes. There is nothing about Kubernetes that requires orchestration to be centralized. Most practitioners who are trying to implement Data Mesh use Kubernetes. 

Actually, my replies to the next 3 bullets about Data Fabric are more or less the same:

"Active metadata management: Heavy use of metadata and knowledge graphs to understand data relationships

AI-driven data integration: Machine learning to automate data integration, quality checks, and recommendations
Unified access layer: Provides a consistent way to access data regardless of where it physically resides"

All of these concepts play a big role in Data Mesh as well. 

"Data Mesh is organizational and cultural (decentralization), while Data Fabric is more technological and architectural (intelligent integration layer)."

That last one is something I think is clearly wrong. The other points had some truth to them, Data Mesh clearly emphasizes distributed governance and ownership more than Data Fabric but Data Mesh very, very clearly is just as much about culture as Data Fabric. Dehgani's book is filled with talk about how you need to change the mindset of your company, how Data Mesh can only work in organizations that have certain qualities and values, etc. Two quotes from her book:

“There is a culture that obsessively runs experiments, observes the results, analyzes the data, makes sense of it, learns from it, and adapts.”
— Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale. https://www.goodreads.com/quotes/12098118-there-is-a-culture-that-obsessively-runs-experiments-observes-the

  “Despite the relentless effort to remove coordination and synchronization in core technologies, we have, for the most part, neglected organizational and architectural coordination.”

https://www.goodreads.com/work/quotes/91270060-data-mesh-delivering-data-driven-value-at-scale  

Michael

On Wed, Jan 28, 2026 at 1:46 AM Alex Shkotin <alex.s...@gmail.com> wrote:

You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/G_uFi5YrCug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAFxxRORjsbCyvo1XiCZkgFj_09mFyTSCQ_VfjjPrsGC4k7buMw%40mail.gmail.com.

[Michael DeBellis]

Bill, 

"Data mesh is object-oriented programming reimagined at an enterprise scale" That's an interesting observation. I haven't heard anyone say that but I was actually thinking the same thing when I was re-reading parts of Dehgani's book yesterday. But I don't agree that Data Mesh is just OOP at enterprise scale but they do have things in common. One of the core ideas of a Data Product is you integrate business logic and data into one large component. Which sounds a whole lot like OOP. There are differences though. I think the most important one is that another core idea of a Data Product is you have both operational data and analytic data (what used to be called OLTP and Data Warehouse) in the same data product. In Dehgani's book she defines "ports" which are essentially interfaces (e.g. defined in GraphQL) to your data and one of the core definitions is that some ports are Operational ports and some are Analytic ports. Actually, here's a diagram I created based on her ideas.Still a work in progress:

Data fabric is a decorative marketing term devised to connote “weaving together” of many systems and has no reasoned engineering substance to it.  I see it as no different than “systems integration” with a little more attention paid to data architecture.

Can't really argue but you could say the same about so many IT terms. I use the term "Neurosymbolic" all the time even though I recognize it is mostly just a marketing term for a fairly basic idea: that a database can support both graphs and large vectors (and my guess is if you talked to people at Triplestore vendors off the record they would agree). I was talking to someone about the way marketing terminology makes IT more complex than it should be last night and my example was Knowledge Management. Back in the 90's everyone was talking about knowledge management and the term got so diluted it was almost meaningless. For Lotus knowledge management was email and threaded discussions, for Documentum knowledge management was document management, for Interwoven Knowledge Management was managing web content. Actually, come to think of it but kind of depressing that I think all 3 companies eventually ended up being gobbled up by IBM. 

Thanks (to everyone) for the feedback.

Michael 

You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/G_uFi5YrCug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/PH3P110MB1777DB5C8205834915500C8A9191A%40PH3P110MB1777.NAMP110.PROD.OUTLOOK.COM.

[Alex Shkotin]

Michael, my experience shows that talking to AI is quite useful. But of course, only you can decide whether it's worth talking to an AI in the spirit of your response to me.

Alex

ср, 28 янв. 2026 г. в 20:19, Michael DeBellis <mdebe...@gmail.com>:

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFikc6gDNg-Y-g9yQ%2BruT_9d%2B4xR3ybH%3D579_7mmOSecjg8w%40mail.gmail.com.

[John F Sowa]

Ravi, Michael, and Mark,

Your definitions  show that the terms data mesh, data fabric, federated, and central are important for certain kinds of software development.  But those issues are many, many levels down from the top levels of an ontology.

The following excerpt from Mark's note shows the issues:  "as you decompose from the "Business" Capability Models (or "Mission" in the defense sector), there are several useful layers before you get to data."

The terms Business and Mission describe things that are important for software design and development.  But the things they do and the data they process are many levels below the top levels of ontology.  I certainly admit that the issues Michael and Mark discussed are important for software development for certain kinds of applications, which are very important for certain kinds of businesses.

Ravi also mentioned LLMs and AI.  These things involve computational methods for processing data that many people, including Michael and Mark, must deal with.  But those methods are totally independent of the ontology of the data.  LLM and AI methods can process any data for representing anything at any level of any ontology.

We have to be very clear about distinguishing the issues of ontology from computational issues and from the subject matter of various kinds of applications.

 

John

---

From: "Ravi Sharma" <drravi...@gmail.com>
Sent: 1/28/26 4:01 AM
To: ontolo...@googlegroups.com
Subject: Re: [ontolog-forum] Data Mesh and Data Fabric

All including Micheal DeBellis

• Federated is where different stakeholders can interoperate in an enterprise Architecture (we are addressing a smaller part relating to data). Their identities, permissions allow them to subset automatically to their permitted areas written in security and business rules / books. Hence vocabularies and semantics and therefore ontologies are relevant.
• Central is where a single controlling authority for validation before interoperation is implied. (rare example, such as Master Data Management). In supply chain one wy management where suppliers can see demand by consolidation of enterprises requirements this is implied as only materials Requirements Planning and execution data are accessible but not manufacturing!

I have not factored LLMs and AI in my comments.

Regards.

Thanks.

Ravi

On Tue, Jan 27, 2026 at 8:33 PM Michael DeBellis <mdebe...@gmail.com> wrote:

Thanks Mark. I'm focusing more on the business world than Defense. Defense is IMO kind of like Healthcare, a very specialized case where the normal rules don't apply. I'm most interested in Internet companies like Amazon, Linked In, Reddit, etc. They tend to lead the way in adopting new ideas. BTW, I agree that LLMs are going to play a big role in all of this. Last year I was reading a book on Data Catalogs and I got to the chapter on Search and thought "well, may as well skip it" because it was written before LLMs took off so IMO it was almost irrelevant. I'm exaggerating to make a point of course but not that much. Thanks for the info.

Michael

https://www.michaeldebellis.com/blog

On Tue, Jan 27, 2026 at 6:34 PM Mark Underwood <know...@gmail.com> wrote:

Michael,

When I looked at this, I thought it was a promising approach -- either fabric or mesh.  But after having seen how these are built and managed, and considering the lack of standards around either, I find the service mesh approach more compelling; see NIST 800-233.

Looking at "data" without its orchestrating tooling and dependencies is a bridge too far, even for limited, domain-specific use cases.  

Which is not to say you can't push all the data you have at the LLM and ask it to make sense of it - schemas, raw code, dictionaries, metadata registries -- because it will help you.

From a pragmatic, consultative point of view, enterprises need to manage ("federate" in a general sense) across multiple abstraction layers. I imagine you can get there through multiple techniques, but as you decompose from the "Business" Capability Models (or "Mission" in the defense sector), there are several useful layers before you get to "data."

At the moment I can't recall the name of the firm whose approach most impressed me.  I'll send it later if I remember it.

You might also want to follow the observability space.  E.g.See this:

...

Also FYI https://www.dtaalliance.org/ 

[Joshua Lieberman]

Hi,

I admit that I was quite puzzled by the proposed definitions and commentary for data fabric and data mesh, then I realized that they completely missed / avoided the central characteristic for which we started applying these terms many years ago, namely the geospatial extent and coverage of data representation across a landscape. For example, Australia and now the U.S. have been developing “hydrofabrics” which consist of data about surface and subsurface hydrology at specified scales and detail (“weave”) covering each nation. While we used “fabric” for the geospatial coverage of data, we tended to use “mesh” to describe the geographic distribution of centralized and edge computing assets, which often ( though not always ) distributed sensing, processing, and storage of data according the same data fabric coverage in order to minimize data transport.

It’s certainly possible, if not frequent, for terms to be adopted / hijacked for completely different purposes, but it would be sad to lose the physical texture of these particular terms, as well as the fairly fundamental concepts for which they have been used.

—Josh Lieberman

On Jan 28, 2026, at 7:31 PM, John F Sowa <so...@bestweb.net> wrote:



--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/d551b60e091c4662a41bf79c572f1aa0%40caa44905bbff49018a04ddaaa0ebda9a.

[John F Sowa]

Joshua,

I agree with your conclusion:   "It’s certainly possible, if not frequent, for terms to be adopted / hijacked for completely different purposes, but it would be sad to lose the physical texture of these particular terms, as well as the fairly fundamental concepts for which they have been used."

That is a major reason for ontology:  Classify the words and concepts precisely so that they are used  correctly in the appropriate contexts.

John

 

---

From: "Joshua Lieberman" <jo...@oklieb.net>

[Michael DeBellis]

Your definitions  show that the terms data mesh, data fabric, federated, and central are important for certain kinds of software development.  But those issues are many, many levels down from the top levels of an ontology.

John, can you explain what you mean by "top levels of an ontology" and how those levels are many levels higher than other kinds of software development? I've  been creating things that I and the people I worked with called ontologies since the 1980's when I worked on a Symbolics machine and used the Knowledge Engineering Environment (KEE) from Intellicorp then later Loom at ISI. We called those models ontologies but we never claimed they were somehow categorically "higher" than other software development tools. 

I've always thought that the most important thing symbolic AI brought to industry were tools that decreased the gap between developers and business users so in the sense of being Very High Level Languages that is what I think OWL is  and also what Loom and KEE were.  But I have a feeling you mean something else than that and I don't understand what that is. 

Michael

https://www.michaeldebellis.com/blog

--
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or
unsubscribe to the forum, see http://ontologforum.org/info
---
You received this message because you are subscribed to a topic in the Google Groups "ontolog-forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ontolog-forum/G_uFi5YrCug/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/d551b60e091c4662a41bf79c572f1aa0%40caa44905bbff49018a04ddaaa0ebda9a.

[Ravi Sharma]

John

Thanks for your comments. I also feel that conceptual and logical data models carry ontologies. In your slides also you have depicted this in the past.

John And Todd  Schneider - Kindly respond to emails in the google group for trustees!

regards.

Thanks.

Ravi

(Dr. Ravi Sharma, Ph.D. USA)

NASA Apollo Achievement Award

Former Scientific Secretary iSRO HQ

Ontolog Board of Trustees

Particle and Space Physics

Senior Enterprise Architect

SAE Fuel Cell Standards Member

You received this message because you are subscribed to the Google Groups "ontolog-forum" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CALGFikd4N4H-bXfvs_pKc%3D5-ebDCXBGH-CpQhLpi%3DJbxVVFLBQ%40mail.gmail.com.

[Alican Tüzün]

Hi Michael,

Probably what John is referring to is "domain agnostic levels" as the top-levels (upper levels) of an ontology. Logically, "function" is nearer to the top, for example, than a more specific domain term like "software development".

LG, 
Alican


  

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAAN3-5dJWR-aDPSZJkBHE0ttuWoFuHaeMVYx%3DULP%3DkJgt%2ByuHA%40mail.gmail.com.

[Alex Shkotin]

Josh, 

IT has been borrowing for a long time and persistently: isn't the Data lake wonderful?

Alex

чт, 29 янв. 2026 г. в 04:37, Joshua Lieberman <jo...@oklieb.net>:

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/4D25C93F-23EA-419D-9CD1-2DD1578EF852%40oklieb.net.

[John F Sowa]

Ravi, Michael, Mark,

Every communication in any notation of any kind is based on some ontology at some level.  

Michael:   can you explain what you mean by "top levels of an ontology" and how those levels are many levels higher than other kinds of software development? I've  been creating things that I and the people I worked with called ontologies since the 1980's when I worked on a Symbolics machine and used the Knowledge Engineering Environment (KEE) from Intellicorp then later Loom at ISI. We called those models ontologies but we never claimed they were somehow categorically "higher" than other software development tools. 

In programming languages, there is no way to define higher or lower.   But in ontology, a concept X is higher than a concept Y if and only if every instance of Y is also an X.

For example, the concept Entity is the highest level of any onto[ogy because everything that exists is an entity.  A process is an entity, a physical object is an entity, a mental thought is an entity  every living thing is an entity, every dead thing is an entity, every computer program, is an entity, etc.

For various languages, the basic concept is generality.  Language L1 is more general than language L2 if and only if any information expressible in L2 may be translated to an equivalent statement in L1, but some statements of L1 cannot be translated to L2..

OWL, for example, is less general than first order logic (FOL) because anything expressed in OWL can be mapped to a statement in FOL.  But many statements in FOL cannot be translated to OWL.

Various logics may also be expressed in exactly equivalent forms in different notations.  People often complain that FOL is hard to read or understand.  But that is just a complaint about notation. It's possible to express every FOL statement in a subset of English, sometimes called Controlled English (CE),  

Anybody who can read English can immediately read and understand CE.  However, it requires a fair amount of practice to learn how to write CE correctly.   A textbook that explains how to write CE would require just as many pages of instructions as one that explains any other notation for FOL.

As for the terms data mesh, data fabric, etc., I suggest that you look at a precise definition of those terms in a precise logic, such as CE.   The most general term is Entity, since everything that exists is an entity.  The level of Entity is defined to be 0.  Every other term in an ontology would be a level 1 or more.

Terms that require more levels of definitions are said to be less general than those that have fewer levels.  The following words belong to the English version of FOL, and they don't have a level: Every, Some, And, Or, Not, If, Then,

Definition of level of generality:  For any word defined by a statement in Controlled English, the word Entity has level 0 and the words of FOL have no level.   For any word X, with a definition in a paragraph of CE sentences, the CE level of X is 1 greater than the largest number of any word in the paragraph that defines X.   For any words X at level n and Y at level m, the word with the larger number is said to be at a lower level.  If n=m, then X and Y are at the same level.

If you want to determine the levels of data mesh or data fabric, just define them precisely and count how many levels occur between Entity and those terms.

John

[Igor Toujilov]

Dear John,
I dare to correct your statement:

"In programming languages, there is no way to define higher or lower.
But in ontology, a concept X is higher than a concept Y if and only
if every instance of Y is also an X."

Actually, in all modern programming languages, there are subclasses
and superclasses.

Regards,
Igor

> --
> All contributions to this forum are covered by an open-source license.
> For information about the wiki, the license, and how to subscribe or
> unsubscribe to the forum, see http://ontologforum.org/info
> ---
> You received this message because you are subscribed to the Google Groups "ontolog-forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ontolog-foru...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/026a78bebd6e4ca897eceb3da9af8672%403d57c1c0fe8b48bd85c0843cdb79678b.

[Neven Knezevic]

Dear Igor,

In no way does this disprove or serve as a counterexample to John's statement. 

1. Object-oriented programming asserts a structure on top of underlying programming paradigms. 

2. Furthermore, there is no strict or prescriptive such structure where that assertion would be clearly independent of the implementation details. It is often the case that we can invert various classes and rearrange them as required. 

3. In code, especially machine code and systems programming languages, there is also no such preference. 

Thank you,

Best,

Neven

To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAKP%2B7LOZmO%3DqTveJmo%2BD5ZrAim97apbEY6tRKxtxPWsTtf4ucA%40mail.gmail.com.

[John F Sowa]

Dear Igor,

I  admit that I should have used the preposition 'among' rather than the more ambiguous 'in'.  Most programming languages have some version of sets or classes.  And they have operators on subsets or subclasses.  

Therefore, the hierarchy of sets or classes is a hierarchy of data types supported by the language, but not a hierarchy among the languages themselves. 

However, it is possible to implement subsets of a very general language.   For example, many programming languages and systems develop over a period of years.  As new kinds of applications arise, those languages may acquire new features to support them.  Therefore, the older versions are sublanguages of the newer versions.

But there is no general hierarchy of all possible programming languages and systems.  You can't define a hiearchy of the languages that support the IBM. Linux, Microsoft, and Apple operating systems.

But it is possible to define a hierarchy (parial orderiing) among all formally defined entities in an ontology -- provided that all definitions are specified in exactly the same logic or family of compatible logics.

However, there is a huge challenge in defining a consistent hierarchy of terms (or words) that are specfied by dictionary definitions in ordinary natural languages (WordNet, for example).  There is also a huge problem in defining a hierarchy among  terms (or words) ithat are in use in all scientific and engineering systems and trying to define a precise hierarchy among all the words used in any or all the natural languages is impossible.

WordNet, for example, is an amazingly accurate accomplishment, but it is only an approximation for many of the types and subtypes.  There have been many attempts to smash formal definitions together in huge conglomerations, but there is no evidence that they're any better than WordNet.

Summary:  The huge conglomerations are better than nothing.  But any attempt to smash together independently developed ontologies is at best a useful approximation for some purposes..

John

 

---

From: "Igor Toujilov' via ontolog-forum" <ontolo...@googlegroups.com>