Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Design Pattern Ontology

328 views
Skip to first unread message

Igor Toujilov

unread,
Nov 25, 2024, 7:41:28 PM11/25/24
to ontolo...@googlegroups.com
Hi All,
I am studying a famous book [1] written by the Gang of Four. I am
surprised that despite it being written 30 years ago, I did not find a
design pattern ontology. There is plenty of material on ontology
design patterns on the Internet, but nothing about a design pattern
ontology which I miss and want to create if it does not exist yet.
Please advise if I overlooked something.

Regards,
Igor

[1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design
patterns : elements of reusable object-oriented software. 1994.

Mike Bennett

unread,
Nov 25, 2024, 7:56:10 PM11/25/24
to ontolo...@googlegroups.com
A design pattern ontology would be a very different thing to an ontology
design pattern, but both are things of value.

At the Object Management Group (OMG) we maintain a suite of standards
based on many of these design patterns, i.e. UML and the underpinnings
in MOF.

We are also exploring whether or how to move some of these modeling
languages from being MOF-based to using the new more semantically rich
framework that has been developed for the SysML V2 standards (which has
a kernel language called KerML). These are still in the Finalization
process.

This is where the distinction between model semantics and the semantics
of the target problem domain subject matter become an important
consideration. For example MOF was all about model element semantics.

Ideally some of these directions will move things towards something with
clear formal semantics both for model semantics and how subject matter
semantics is treated. Whether that's in KerML or a more conventional
ontology standard such as FOL or DL, or a syntax such as RDF/OWL,
remains to be seen.

If anyone did happen to be doing a formal ontology of these software
design patterns, this would be very helpful to know.

Meanwhile you should probably also check out the OMG's ESSENCE standard
(spearheaded by Ivar Jacobson) for the kind of model concepts needed to
model a design methodology.

Mike

Alex Shkotin

unread,
Nov 26, 2024, 3:10:56 AM11/26/24
to ontolo...@googlegroups.com
Interesting topics.
And google search for 
"software design patterns catalog" as ontology is at first cut an advanced catalog
and "software design patterns ontology" 
return promising URLs to begin with.

And I asked Gemini: " But I need ontology for software design patterns." It does not know about [1].

Alex

While there isn't a widely recognized, standardized ontology specifically designed for software design patterns, the concept of using ontologies to represent and reason about software design patterns is an active area of research.

Here's how ontologies can be applied to software design patterns:

1. Formalizing Pattern Knowledge:

  • Capturing Core Concepts: Define classes for patterns, their intents, problems, solutions, and participants.
  • Establishing Relationships: Model relationships between patterns, such as inheritance, composition, and usage scenarios.
  • Representing Contextual Information: Incorporate information about the patterns' applicability, trade-offs, and potential anti-patterns.

2. Enabling Pattern Discovery and Recommendation:

  • Semantic Search: Use ontology-based search techniques to find relevant patterns based on specific requirements.
  • Pattern Matching: Identify potential pattern matches within existing codebases using ontology-driven analysis.
  • Recommendation Systems: Develop intelligent systems that recommend appropriate patterns based on the context of the software development project.

3. Supporting Automated Reasoning and Code Generation:

  • Rule-Based Systems: Use ontologies to create rule-based systems that can automatically apply patterns to code.
  • Model-Driven Development: Integrate ontologies into model-driven development processes to generate code from high-level design models.

4. Facilitating Knowledge Sharing and Collaboration:

  • Common Vocabulary: Establish a shared vocabulary for discussing design patterns, promoting better communication and understanding.
  • Collaborative Development: Use ontologies to support collaborative development efforts, enabling teams to work together more effectively.

Challenges and Considerations:

  • Ontology Development: Creating a comprehensive and accurate ontology for software design patterns requires significant effort and expertise.
  • Semantic Interoperability: Ensuring interoperability between different ontologies is crucial for effective knowledge sharing and reuse.
  • Scalability: As the number of patterns and their relationships grows, the ontology may become complex and difficult to maintain.

Potential Benefits:

  • Improved Design Quality: By providing a formal framework for understanding and applying patterns, ontologies can help developers create more robust and maintainable software.
  • Enhanced Collaboration: Ontologies can facilitate knowledge sharing and collaboration among software development teams.
  • Automated Tools and Techniques: Ontology-based tools can automate various aspects of the software development process, such as code generation and refactoring.

While there's still much work to be done in this area, the potential benefits of using ontologies for software design patterns are significant. By addressing the challenges and leveraging the opportunities, researchers and practitioners can advance the state of the art in software engineering.


вт, 26 нояб. 2024 г. в 03:56, Mike Bennett <mben...@hypercube.co.uk>:
--
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/089e3b0a-dd6a-4968-8969-1eedb6de7da9%40hypercube.co.uk.

John F Sowa

unread,
Nov 26, 2024, 6:15:14 PM11/26/24
to ontolo...@googlegroups.com, CG, ontolog...@googlegroups.com
Mike and Igor,

I'm glad that you mentioned design patterns.  But instead of an ontology of design patterns, I would say that design patterns should be the BASIS for ontology.  In fact, I would point out that visualization and conceptualization are the basis for mathematics.  The formal notation always comes at the end, never at the beginning.

The term 'design pattern' is for the kinds of visualizations that mathematicians and logicians start with.  The formal notations are essential, but creative mathematicians always start with visual patterns long before they get down to the formal details.  In fact, mathematicians usually have the problem completely solved in diagrams long before they work out the formal notations.

The formalism is essential to verify that the visualization is correct and to specify every last detail.  And the task of writing out the formal details can often point out issues that were missing or mistaken in the visualization.  Visualization is the essence of mathematics.  Formalization is the housekeeping that is important for keeping everything neat and tidy.

More generally, I would emphasize the trio of Conceptualization, Analysis, and Formalization.  We need all three.   For comments by Paul Halmos (a former president of the American Mathematical Society) and Albert Einstein, see the following slide 27.  For more discussion and references, see https://jfsowa.com/talks/eswc.pdf .



 


From: "Mike Bennett" <mben...@hypercube.co.uk>

Kingsley Idehen

unread,
Nov 27, 2024, 8:32:36 AM11/27/24
to ontolo...@googlegroups.com

Hi John,

I’ve used your https://jfsowa.com/talks/eswc.pdf reference to generate an article using following workflow, courtesy of our AI Middleware Layer using OpenAI’s GPT-4o language model API:

  1. Summarize https://jfsowa.com/talks/eswc.pdf.

  2. Redo, but incorporating the following:

    • FAQ – minimum 10 questions
    • HowTo – to the degree relevant
    • Glossary – minimum 10 key terms
  3. Improve by adding a section titled “Contemporary View in the Age of LLM-based Natural Language Processors”:

    • How do LLMs change the tooling available for generating and integrating Ontologies?
    • How do LLMs change the workflow associated with semantic integration informed by Ontologies?
    • How do LLMs affect the practical aspects of ontology-informed integration of data, information, and knowledge?
  4. Redo, but in a markdown block.

  5. Improve by incorporating the quotes in the attached image.

Article Generated from PDF

Summary of “Knowledge Representation: Logical, Cognitive, and Computational Foundations” by John F. Sowa

This document explores the integration of logic, cognitive science, and computation in knowledge representation (KR) and its applications to the Semantic Web. It provides insights into foundational principles, challenges, and future directions in building intelligent systems that align with human understanding. Additionally, it discusses the transformative impact of modern tools like Large Language Models (LLMs) on traditional KR workflows, particularly in the domains of ontology generation, semantic integration, and data-driven reasoning.


Visualization in Knowledge Representation: Insights from Mathematics and Physics

The Creative Role of Visualization

The process of knowledge representation, much like the creative process in mathematics and physics, is deeply visual and conceptual. Sowa’s ideas align with the insights of mathematician Paul Halmos and physicist Albert Einstein:

  1. Paul Halmos on Mathematics:
    Halmos suggests that the act of doing mathematics is not inherently deductive but rather imaginative. A mathematician’s work involves “vague guesses, visualizing broad generalizations, and jumping to unwarranted conclusions” to gain insight. He highlights the distinction between the creative and deductive stages of reasoning, where proving rigorously is more of a technical task that follows the initial creative insight.

    “The deductive stage, writing the results down, and writing its rigorous proof are relatively trivial once the real insight arrives; it is more the draftsman’s work, not the architect’s.” — Halmos (1968)

  2. Albert Einstein on Physics:
    Einstein emphasizes that thought, especially his, is largely non-verbal and visual. He describes ideas as associative images that are “voluntarily reproduced and combined”, with words coming only as a secondary process after visualization and mental modeling.

    “The words or the language, as they are written or spoken, do not seem to play any role in my mechanism of thought… The above-mentioned elements are, in my case, of visual and some of muscular type.” — Quoted by Hadamard (1945)

Relevance to KR:
Both Halmos and Einstein underline the significance of visualization and conceptualization in the creative process. Similarly, in KR, the conceptual graph and ontology modeling stages often mirror this visual, creative phase, while the deductive reasoning and querying processes align with the draftsman’s work of formalization. The interplay of these two stages is crucial for developing effective KR systems.


FAQ (Frequently Asked Questions)

  1. What is Knowledge Representation (KR)?
    KR is a method of encoding information so that both humans and machines can interpret, reason, and use it.

  2. Why is KR important for the Semantic Web?
    KR enables meaningful integration of data across diverse domains, supporting reasoning and query answering in distributed environments.

  3. What are the main challenges in KR?

    • Balancing expressivity and computational efficiency.
    • Semantic alignment across disparate ontologies.
  4. How do Conceptual Graphs (CGs) relate to KR?
    CGs are a visual, logic-based notation inspired by Charles Sanders Peirce that facilitates reasoning and data integration.

  5. What is the relationship between KR and cognitive science?
    KR draws on human cognitive processes to design systems that reason intuitively and interact effectively with users.

  6. How do RDF, OWL, and SPARQL fit into KR?
    These are tools and languages that implement KR principles for structuring, querying, and reasoning with web data.

  7. How do LLMs affect ontology generation?
    LLMs automate concept extraction, align schemas, and assist in iterative refinement, reducing manual effort.

  8. What reasoning methods are emphasized in KR?
    Deductive reasoning is primary, but inductive and abductive reasoning are also important for dealing with uncertainty and incomplete data.

  9. What role does scalability play in KR?
    Scalable KR systems can manage the vast data of the Semantic Web while maintaining reasoning capabilities.

  10. What are the future directions for KR?
    Future research emphasizes hybrid reasoning systems, commonsense knowledge, and dynamic, context-aware ontologies.


HowTo: Implement Key Concepts

  1. Building a Knowledge Graph:

    • Identify entities and relationships in your domain.
    • Use RDF and OWL to define semantic structures.
    • Leverage tools like SPARQL for querying and linking data.
  2. Creating Conceptual Graphs (CGs):

    • Start with a logical representation of your knowledge (e.g., subject-predicate-object).
    • Use CG notation to diagram entities, relationships, and constraints.
    • Apply Peirce’s existential graphs for reasoning tasks.
  3. Integrating Ontologies:

    • Use tools like Protégé to define and align ontologies.
    • Employ semantic integration techniques to resolve mismatches between data schemas.
  4. Reasoning with KR:

    • Apply deductive reasoning for strict logic.
    • Incorporate abductive reasoning to hypothesize explanations for observed phenomena.
    • Use inductive reasoning for generalizing from patterns.
  5. Leveraging LLMs for KR:

    • Automate ontology generation by extracting entities and relationships from unstructured data.
    • Use natural language queries to interact with knowledge graphs via SPARQL translations.
    • Dynamically refine semantic integration tasks with LLM-driven context analysis.

Contemporary View in the Age of LLM-based Natural Language Processors

1. LLMs and Ontology Generation

LLMs simplify and accelerate ontology development by:

  • Extracting Concepts and Relationships: Automating the identification of entities, attributes, and relationships from unstructured text.
  • Populating Ontologies: Adding instances to existing ontologies or creating entirely new structures with minimal human intervention.
  • Semantic Alignment: Mapping disparate ontologies through pattern recognition and contextual reasoning.
  • Human-Readable Documentation: Generating plain-language descriptions of complex ontologies for broader accessibility.

2. LLMs and Semantic Integration Workflows

LLMs redefine semantic integration workflows by:

  • Dynamic Schema Mapping: Identifying relationships between schemas without predefined ontologies.
  • Disambiguating Concepts: Leveraging context from data to resolve ambiguities and inconsistencies during integration.
  • Interactive Refinement: Facilitating collaboration between human experts and AI for iterative improvements.
  • Enhanced Reasoning: Using ontologies as guides for refining integration processes and ensuring consistency.

3. LLMs and Ontology-Informed Data Integration

LLMs affect practical aspects of data integration by:

  • Processing Unstructured Data: Extracting actionable insights and linking them to structured ontologies to enrich knowledge graphs.
  • Natural Language Query Support: Translating conversational queries into SPARQL or SQL for seamless interaction with knowledge bases.
  • Continuous Evolution: Dynamically adapting ontologies to reflect new data, ensuring relevance and accuracy.

Impact: LLM-powered KR systems are more adaptive, scalable, and accessible, enabling organizations to operationalize linked data principles effectively.


Glossary of Key Terms

  1. Knowledge Representation (KR): The process of modeling information so that it can be easily interpreted and reasoned about by humans and machines.
  2. Semantic Web: A framework for enabling data to be shared and reused across applications, enterprises, and communities using standard formats.
  3. Ontology: A formal specification of concepts, relationships, and constraints within a domain.
  4. Conceptual Graphs (CGs): A graphical representation of logical propositions based on Peirce’s ideas.
  5. Existential Graphs: A visual logic system created by Peirce, foundational to modern KR techniques.
  6. Deductive Reasoning: Deriving logically certain conclusions from premises.
  7. Abductive Reasoning: Inferring the most likely explanation for a set of observations.
  8. Inductive Reasoning: Generalizing conclusions from specific instances.
  9. RDF (Resource Description Framework): A standard model for data interchange on the web.
  10. SPARQL: A query language used to retrieve and manipulate data stored in RDF format.

Closing Note

The integration of LLMs into KR workflows marks a new era for the Semantic Web. By bridging symbolic reasoning, cognitive insights, and computational efficiency, LLMs empower systems to address real-world challenges with greater accuracy and scalability. Much like Halmos and Einstein’s insights into visualization in creative processes, KR systems increasingly leverage visual and conceptual models to align with human reasoning and foster innovation.

Related

-- 
Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com
Community Support: https://community.openlinksw.com

Social Media:
LinkedIn: http://www.linkedin.com/in/kidehen
Twitter : https://twitter.com/kidehen


Igor Toujilov

unread,
Nov 27, 2024, 8:38:33 AM11/27/24
to ontolo...@googlegroups.com
John,
I agree that visualisation is important in formal reasoning. But I am not sure that it works in all cases. I have seen theoretical physicists discussing their problems on YouTube for hours without a single diagram. It seems they operate mathematical formulas in their mind. They use some gestures, but no diagrams which would not be much helpful to present things in a high-dimensional space.

--
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.

Kingsley Idehen

unread,
Nov 27, 2024, 8:42:18 AM11/27/24
to ontolo...@googlegroups.com
Hi Igor,

On 11/27/24 8:38 AM, 'Igor Toujilov' via ontolog-forum wrote:
> John,
> I agree that visualisation is important in formal reasoning. But I am
> not sure that it works in all cases. I have seen theoretical
> physicists discussing their problems on YouTube for hours without a
> single diagram.

IMHO:

That doesn’t mean they didn’t use a diagram during the early conceptual
stages, or even have one off-camera. As visual beings, any
well-thought-out process typically begins with some form of conceptual
visualization—unless it’s just copying, memorizing, and regurgitating
someone else’s work. :)

Ravi Sharma

unread,
Nov 29, 2024, 12:43:09 PM11/29/24
to ontolo...@googlegroups.com
In the software development and maturity considerations we used to talk of design, development and implementation patterns.
Would you then build three different ontologies?
I would think only one would be applicable for all three types of patterns.

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



--
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.

Igor Toujilov

unread,
Nov 29, 2024, 1:21:59 PM11/29/24
to ontolo...@googlegroups.com
Ravi,
Thank you for reminding me.
I agree. The ontology should integrate all those patterns. It can be
modular where each module is devoted to a narrower aspect. But the
integrated ontology should combine all those modules.
Also analysis patterns are relevant here. Some years ago, I read an
excellent book by Martin Fowler about analysis patterns.
> To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/CAAN3-5fRjN4GD16ubRYG9Zf8VQvxZgyRzheKVJ92QEa8vqem3Q%40mail.gmail.com.

Alex Shkotin

unread,
Nov 30, 2024, 3:29:50 AM11/30/24
to ontolo...@googlegroups.com
Hi Kingsley,

And let me add that almost any complex mathematical formula, especially in physics, is a two-dimensional diagram, i.e., not linear.
Like this
image.png
Visual thinking is a power of the mind.

Alex


ср, 27 нояб. 2024 г. в 16:42, 'Kingsley Idehen' via ontolog-forum <ontolo...@googlegroups.com>:
--
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.

John F Sowa

unread,
Nov 30, 2024, 8:42:09 PM11/30/24
to ontolo...@googlegroups.com
Ravi, Igor, and Kingsley,

Since Matthew isn't with us, I'll summarize some of his points which we had discussed over many years in different ways.

He had been working at Shell Oil for years, and he had developed a detailed ontology for the oil industry.  He later generalized it to develop a more general top level, which I considered quite good.   We had discussed issues about generalizing it even farther,  but he was reluctant to go farther in levels of abstraction.   We agreed that was a reasonable point of view.

But we also agreed that his details for the oil industry might conflict with details for other industries, such as banking and farming.   Furthermore, he recognized that different oil companies had different ways of representing the same terms because they had developed different policies and procedures.

I'll also mention another widely used ontology, which evolved over a period of about 70 years, and it is unlikely to change for a long, long time:  the ontology for making reservations for airlines, which was later extended to cover anything related to airlines, such as hotels, car rentals, trains, taxis, etc., etc.

And that ontology began in the 1950s with IBM's project SAGE for the airplanes used in the Strategic Air Command  over North America.  In the 1960s, IBM adapted that ontology for American Airlines.  IBM later sold the software to other airlines.   And all the other additions were made to conform to the same basic ontology from the 1950s.  70 years later, that top level is so entrenched that it is never going away.

Another world-wide ontology that also developed in the 1960s includes the global weather patterns that were established by the world-wide weather simulation programs.  They use a different way of representing the world than the reservation systems.

Fundamental problem:  There will never be a single universal ontology for representing anything and everything in the world (or the universe).

That is a fact that any system of knowledge representation must deal with.

John
 


From: "Ravi Sharma" <drravi...@gmail.com>

In the software development and maturity considerations we used to talk of design, development and implementation patterns.
Would you then build three different ontologies?
I would think only one would be applicable for all three types of patterns.

Thanks.
Ravi

On Wed, Nov 27, 2024 at 5:42 AM 'Kingsley Idehen' via ontolog-forum <ontolo...@googlegroups.com> wrote:

Kingsley Idehen

unread,
Dec 1, 2024, 11:25:40 AM12/1/24
to ontolo...@googlegroups.com

Hi John,

On 11/30/24 8:41 PM, John F Sowa wrote:
Ravi, Igor, and Kingsley,

Since Matthew isn't with us, I'll summarize some of his points which we had discussed over many years in different ways.

He had been working at Shell Oil for years, and he had developed a detailed ontology for the oil industry.  He later generalized it to develop a more general top level, which I considered quite good.   We had discussed issues about generalizing it even farther,  but he was reluctant to go farther in levels of abstraction.   We agreed that was a reasonable point of view.

But we also agreed that his details for the oil industry might conflict with details for other industries, such as banking and farming.   Furthermore, he recognized that different oil companies had different ways of representing the same terms because they had developed different policies and procedures.

I'll also mention another widely used ontology, which evolved over a period of about 70 years, and it is unlikely to change for a long, long time:  the ontology for making reservations for airlines, which was later extended to cover anything related to airlines, such as hotels, car rentals, trains, taxis, etc., etc.

And that ontology began in the 1950s with IBM's project SAGE for the airplanes used in the Strategic Air Command  over North America.  In the 1960s, IBM adapted that ontology for American Airlines.  IBM later sold the software to other airlines.   And all the other additions were made to conform to the same basic ontology from the 1950s.  70 years later, that top level is so entrenched that it is never going away.

Another world-wide ontology that also developed in the 1960s includes the global weather patterns that were established by the world-wide weather simulation programs.  They use a different way of representing the world than the reservation systems.

Fundamental problem:  There will never be a single universal ontology for representing anything and everything in the world (or the universe).

That is a fact that any system of knowledge representation must deal with.

John


I completely agree with your perspective on ontologies and practical reality. Hopefully, the rise of LLMs will simplify these concepts by enabling quicker experimentation with ontologies, ultimately reinforcing this crucial point.

Kingsley

 


From: "Ravi Sharma" <drravi...@gmail.com>

In the software development and maturity considerations we used to talk of design, development and implementation patterns.
Would you then build three different ontologies?
I would think only one would be applicable for all three types of patterns.

Thanks.
Ravi

On Wed, Nov 27, 2024 at 5:42 AM 'Kingsley Idehen' via ontolog-forum <ontolo...@googlegroups.com> wrote:
Hi Igor,

On 11/27/24 8:38 AM, 'Igor Toujilov' via ontolog-forum wrote:
> John,
> I agree that visualisation is important in formal reasoning. But I am
> not sure that it works in all cases. I have seen theoretical
> physicists discussing their problems on YouTube for hours without a
> single diagram.

IMHO:

That doesn’t mean they didn’t use a diagram during the early conceptual
stages, or even have one off-camera. As visual beings, any
well-thought-out process typically begins with some form of conceptual
visualization—unless it’s just copying, memorizing, and regurgitating
someone else’s work. :)

--
Regards,

Kingsley Idehen
--
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.

Michael DeBellis

unread,
Dec 21, 2024, 12:33:00 AM12/21/24
to ontolog-forum
Igor, to the best of my knowledge there isn't one and that is  something I've thought would be good to build for quite a while.   BTW, Martin Fowler also has a good book on Analysis patterns.   I've also thought an ontology of refactoring and data pipeline transformations might be useful. Both to model patterns in general and for those that are specific to ontologies and knowledge graphs. Also, for refactoring of ontologies/knowledge graphs SPARQL combined with a programming language would be an excellent way to implement them. E.g., have Python functions like change_iri, splice_class, merge_classes, refactor_data_to_object_property,... When I worked on the Knowledge-Based Software Assistant (KBSA) program my team at Accenture and Lewis Johnson's team at ISI developed the idea of Evolution Transformations which were automated refactoring, just we focused on spec languages rather than programming languages. We met with Ralph Johnson and others to talk about how the ideas were similar and the OOP and formal methods KBSA groups could work together. 

I've always thought it would be a good idea to have a whole library of such refactoring transformations for knowledge graphs. Other examples would be transforming SWRL rules to SPARQL SPIN (much faster and many reasoners optimized for large graphs don't support SWRL). I was actually going to build that a while ago but then I did a search and someone beat me to it but I've never had a chance to try out his implementation. Also, transforming OWL restrictions to SHACL constraints. I've done this kind of thing countless times, actually in every ontology I've ever built that had to integrate with real data. Inevitably we would have OWL axioms like the datatype of some property must be xsd:decimal but the input data always had bad data  so the ontology would never be consistent if it was getting regular updates from relational databases and other sources. We didn't use SHACL because it was easier to just remove the datatype restriction and use SPARQL to transform the bad data and then convert all the data to be the appropriate datatypes after cleaning the data. Of course another approach would be to clean the data before it gets into the knowledge graph but in my experience that tends to be difficult for other reasons. E.g., a lot of times to transform the data you need to use other data that was loaded. But I think the better way to do that might be to convert some axioms from OWL to SHACL. I know the dogma is "OWL is for reasoning and SHACL is for data restrictions" but in my experience the distinction isn't always so clear cut. 

Cheers, 
Michael

Igor Toujilov

unread,
Dec 22, 2024, 4:26:15 PM12/22/24
to ontolo...@googlegroups.com
Michael,
Yes, I mentioned Martin Fowler's Analysis Patterns in this thread
before. Ontologies of other related domains could be useful as well.

Cheers,
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/2a9c9c9b-dffa-4703-bedc-1c03cff05975n%40googlegroups.com.

Burkett, William [USA]

unread,
Dec 30, 2024, 12:14:29 PM12/30/24
to ontolo...@googlegroups.com

In the “data modelling world” (which, to me, is not different than the “ontology world”), there are books by David Hay and Len Silverston that are overtly focuses on design patterns:

 

Hay, D. C. (1996). Data model patterns : conventions of thought. New York, Dorset House Pub.

Hay, D. C. (2006). Data model patterns : a metadata map. Amsterdam ; Boston, Elsevier Morgan Kaufmann.

Silverston, L. (2009). The data model resource book, Vols 1-3. New York, John Wiley.

 

These books provide a catalog of reusable and adaptable patterns for all kinds of concepts that recur in most data models/ontologies.

 

Bill Burkett

 

 

 

From: 'Igor Toujilov' via ontolog-forum <ontolo...@googlegroups.com>
Sent: Sunday, December 22, 2024 2:26 PM
To: ontolo...@googlegroups.com
Subject: [External] Re: [ontolog-forum] Re: Design Pattern Ontology

> ---
> 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.
 
-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
--- 
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.

Mike Peters

unread,
Dec 30, 2024, 1:19:44 PM12/30/24
to ontolo...@googlegroups.com
Hi Bill

I agree; those are excellent books. Their work or influence is the basis for every relational database I have built.

David Hay also wrote this one:

Hay, D. C. (2011). UML and Data Modeling: A Reconciliation, Technics Publications.

I found it very helpful. It's a pity he never wrote a book on data modelling ontologies.

Mike Peters
-----------------------------------
Ajabbi
 
PO Box 902
Invercargill 9840
New Zealand
 
M 64+ 22 600 5006
Skype redworksnz
 
Art Studio www.redworks.co.nz 
Software Architecture www.blog.ajabbi.com
------------------------------------------


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/RL97zvkBBMg/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/BY3PR06MB8131509F91C90BC40DDEEFF291092%40BY3PR06MB8131.namprd06.prod.outlook.com.

Virus-free.www.avast.com

deddy

unread,
Dec 30, 2024, 1:32:15 PM12/30/24
to ontolo...@googlegroups.com
Mike -

>
> pity he never wrote a book on data modelling ontologies.
>

The distinction / difference between data models & ontologies is what...?

______________________
David Eddy
> > FROM: 'Igor Toujilov' via ontolog-forum
> > <ontolo...@googlegroups.com>
> > SENT: Sunday, December 22, 2024 2:26 PM
> > TO: ontolo...@googlegroups.com
> > SUBJECT: [External] Re: [ontolog-forum] Re: Design Pattern Ontology
> Virus-free.www.avast.com
>
> --
> 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/CAE8bvLODb05CZtGzduP5X4SxsWKAWDyHSSP5SrEAT%3DuZmjdJjQ%40mail.gmail.com.
>

Mike Peters

unread,
Dec 30, 2024, 2:14:44 PM12/30/24
to ontolog-forum
Hi David

Great question.

Ontologies are represented in graph structures. Non-relational databases like semantic or graph databases are better suited for this job, and ontologists (I'm not one) have no problem working with them.

However, the workforce needs conventional everyday interfaces driven by relational databases. So, there is an import/export issue that David Hay could have written a book about, and I wish he had. His explanations are excellent. His book on UML and data modelling also bridged two different ways of looking at the world.

Mike


Michael DeBellis

unread,
Dec 30, 2024, 2:16:20 PM12/30/24
to ontolo...@googlegroups.com
The distinction / difference between data models & ontologies is what...?

I think there is a difference but it isn't what many people in the ontology community seem to think. Most of the methodologies and guidelines I've seen for building ontologies present the ontology as a thing in itself. For example, they often minimize or even ignore questions such as loading data or integrating with existing systems. In reality these are some of the most important issues to face for ontologies used in the real world. Some of the most important distinctions between an E/R model and an ontology are:

1) E/R models are typically used for Online Transaction Processing (OLTP) ontology and knowledge graph models are typically used for Online Analytic Processing (OLAP). The design of an OLTP model needs to be optimized for response time. Thus, such models tend to be fairly sparse, leaving most of the domain knowledge in the code of the systems that use them. The design for an OLAP model can be much richer and include much more knowledge about the domain in the model itself rather than in the code because the users will tend to be working on client machines that have more processing power and because they are going to be executing complex queries will be a bit more patient than someone adding a post to Facebook or doing a funds transfer on their bank account with their phone. 

2) E/R models need to worry about various normalization forms for peak efficiency depending on what needs to be maximized. Ontologies are implemented as graphs and don't need to consider the same kinds of issues. Essentially when you build an ontology you are able to work at the analysis level whereas for an E/R model you tend to work at the design level. 

3) E/R models are relatively difficult to change at run time. Ontologies and knowledge graphs can easily be changed at run time, not just the instance values but the schemas themselves can be changed at run time. In this way they are more similar to NoSQL databases that have "schema on read" rather than E/R models that have schema on write. 

Actually, I just remembered I'm putting together a table comparing relational databases, NoSQL (Hadoop) and OWL. Here's what I have so far. This is a work in progress:

Feature

Hadoop (HDFS + Pig/Hive)

SQL Databases

OWL Knowledge Graphs (e.g., AllegroGraph)

Schema

Schema on read

Schema on write

Schema on write but schema can be modified at run time

Data Model

File-based (raw formats)

Tables (rows/columns)

RDF triples or quads (subject-predicate-object)

Storage

Distributed (HDFS)

Centralized or sharded

Triple or quad stores with distributed options and sharding

in some triplestores (e.g., AllegroGraph)

Processing

Batch (MapReduce)

Transactional (ACID)

Semantic reasoning and SPARQL queries. Some triplestores also

support ACID transactions.

Querying

Pig Latin, HiveQL

SQL

SPARQL and Description Logic queries

Reasoning

None

None

SWRL, SHACL, OWL DL axioms

Flexibility

Flexible (unstructured, semi-structured, structured)

Rigid schema

Highly flexible with semantic annotations and Linked Data

Scalability

Horizontal (many nodes)

Vertical (more powerful nodes)

Horizontal or vertical, depending on implementation

Integration

Tools for ETL and analytics

Tight coupling with apps

Can integrate with ontologies, Linked Data, and other RDF graphs

Best For

Batch processing, raw data storage

Transactional workloads, OLTP

Semantic data, reasoning, and complex relationships


deddy

unread,
Dec 30, 2024, 2:25:12 PM12/30/24
to ontolo...@googlegroups.com
Mike -

>
> driven by relational databases.
>

You might want to add this site to your reading list.


https://www.db-engines.com/en/ranking list of DBMSs



DBMS engine tally at 417 as of 2024-01-04

Their counting system gets a little wonky at 390+

______________________
David Eddy


>  -------Original Message-------
>  From: Mike Peters <mi...@redworks.co.nz>
>  To: ontolog-forum <ontolo...@googlegroups.com>
>  Subject: Re: [External] Re: [ontolog-forum] Re: Design Pattern Ontology
>  Sent: Dec 30 '24 14:14
>  
>  Hi David
>  
>  Great question.
>  
>  Ontologies are represented in graph structures. Non-relational
>  databases like semantic or graph databases are better suited for this
>  job, and ontologists (I'm not one) have no problem working with them.
>  
>  However, the workforce needs conventional everyday interfaces driven
>  by relational databases. So, there is an import/export issue that
>  David Hay could have written a book about, and I wish he had. His
>  explanations are excellent. His book on UML and data modelling also
>  bridged two different ways of looking at the world.
>  
>  Mike
>  
>  https://groups.google.com/d/msgid/ontolog-forum/0be48563-c31a-4a39-b6a1-4a0f6852a52dn%40googlegroups.com.
>  

deddy

unread,
Dec 30, 2024, 2:33:12 PM12/30/24
to ontolo...@googlegroups.com
Michael -

>
> Most of the methodologies and guidelines I've seen for building
> ontologies present the ontology as a thing in itself.
>

That is a realistic definition / description I can live with.


Fifteen years ago I one-on-one asked Jim Hendler if there were anything in "the SemWeb stack" for operational, legacy systems.... his instant response was an emphatic "No!"

When the opportunity presents itself, I will endeavor to determine if he has altered his position.
> https://groups.google.com/d/msgid/ontolog-forum/CALGFikdhFVkKo3PSM2xoK3G21hVi2Le0dM7UF8-FBZvWzoMrwA%40mail.gmail.com.
>

Mike Peters

unread,
Dec 30, 2024, 2:42:51 PM12/30/24
to ontolog-forum
Hi Michael

Thank you for that excellent side-by-side comparison of the differences between E/R models and ontologies. I hope you publish it again when you have finished; it's really important for someone working in relational databases who needs to import ontologies and put them to practical use by real people.

David, thank you for the reference. I had come across this before. What an enormous list.

Mike

Paul Tyson

unread,
Dec 30, 2024, 2:44:38 PM12/30/24
to ontolo...@googlegroups.com


On 12/30/24 13:33, deddy wrote:
Michael -

Most of the methodologies and guidelines I've seen for building 
ontologies present the ontology as a thing in itself.

That is a realistic definition / description I can live with.


Fifteen years ago I one-on-one asked Jim Hendler if there were anything in "the SemWeb stack" for operational, legacy systems.... his instant response was an emphatic "No!"

2024 - P15Y = 2009 < 2012 (date of R2RML recommendation)

Best,
--Paul

Igor Toujilov

unread,
Dec 30, 2024, 3:30:11 PM12/30/24
to ontolo...@googlegroups.com
Bill,
Thanks; Yes, those books are valuable resources to study and use when
building design pattern ontologies.

Igor
> 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/BY3PR06MB8131509F91C90BC40DDEEFF291092%40BY3PR06MB8131.namprd06.prod.outlook.com.

Igor Toujilov

unread,
Dec 30, 2024, 4:57:29 PM12/30/24
to ontolo...@googlegroups.com
Mike,
I would not say "Ontologies are represented in graph structures" only.
Ontologies can be represented in a wide range of formalisms, including
graphs, which are just one possible representation. For example, there
are tools to store the same ontology in different representation
formats: RDF/XML, Turtle, OWL Functional Syntax, Manchester OWL
Syntax, etc. Yes, RDF and Turtle are graph representations. But OWL
Functional and Manchester syntaxes have nothing to do with graphs. And
yet they represent the same ontology.

I also disagree that "the workforce needs conventional everyday
interfaces driven by relational databases". It depends on your system
architecture. Today many systems use No-SQL or graph databases
successfully without any need for relational databases.

In real systems, the difference between data models and ontologies can
be sharp or subtle. Some systems continue using relational databases
while performing some tasks on ontologies. Other systems have
ontologies that are tightly integrated in the production process, so
sometimes it is hard to separate the ontologies from data. And of
course, there is a wide range of systems in between of those extreme
cases.

Igor
> To view this discussion visit https://groups.google.com/d/msgid/ontolog-forum/0be48563-c31a-4a39-b6a1-4a0f6852a52dn%40googlegroups.com.

Burkett, William [USA]

unread,
Dec 30, 2024, 5:18:08 PM12/30/24
to ontolo...@googlegroups.com
>> The distinction / difference between data models & ontologies is what...?

 

My take is that the difference is primarily one of intention.  Ontology designers and “conceptual data model” designers are seeking to create representations of the “real world”.  Logical/physical data designers are seeking to create specifications for actual data structures for applications to store/access/use data.  This is distinction is, of course, very fuzzy and fluid because both sets of designers are usually pursuing both of these intentions simultaneously.  If an “ontology” is specified in OWL, it is, of course, is a self-defining “data structure” that is processable by applications designed to use that structure – so, IMHO, there is no objective, practical difference between them.  Unless we’re talking about box-and-line diagrams, most ontologies that we talk about here (I think) are just special kinds of data models. 

 

Bill Burkett

 

From: 'Igor Toujilov' via ontolog-forum <ontolo...@googlegroups.com>
Sent: Monday, December 30, 2024 2:57 PM
To: ontolo...@googlegroups.com
Subject: Re: [External] Re: [ontolog-forum] Re: Design Pattern Ontology

 

Mike, I would not say "Ontologies are represented in graph structures" only. Ontologies can be represented in a wide range of formalisms, including graphs, which are just one possible representation. For example, there are tools to store the

>> > > ---
>> > > You received this message because you are subscribed to a topic in
>> > > the Google Groups "ontolog-forum" group.
>> > > To unsubscribe from this topic, visit
>> > >
>> > > To unsubscribe from this group and all its topics, send an email to
>> > > ontolog-foru...@googlegroups.com.
>> > > To view this discussion visit
>> > >
>> >
>> > --
>> > All contributions to this forum are covered by an open-source
>> > license.
>> > For information about the wiki, the license, and how to subscribe or
>> > ---
>> > 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
>> >
> 
> --
> All contributions to this forum are covered by an open-source license.
> For information about the wiki, the license, and how to subscribe or
> ---
> 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.
 
-- 
All contributions to this forum are covered by an open-source license.
For information about the wiki, the license, and how to subscribe or 
--- 
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.

David Eddy

unread,
Dec 30, 2024, 6:23:59 PM12/30/24
to ontolo...@googlegroups.com
Bill -


On Dec 30, 2024, at 5:17 PM, 'Burkett, William [USA]' via ontolog-forum <ontolo...@googlegroups.com> wrote:

If an “ontology” is specified in OWL

I’ll ask a systems security — ACF2, TopSecret, RACF — buddy if he’s ever heard of OWL. 

I’m betting no.


Conversely… I assume few people on this list have any idea what  ACF2, TopSecret, & RACF are.

- David

Alex Shkotin

unread,
Dec 31, 2024, 3:30:33 AM12/31/24
to ontolo...@googlegroups.com
Hi Michael

Your table reminds me "What Goes Around Comes Around… And Around… Michael Stonebraker and Andrew Pavlohttps://sigmodrecord.org/2024/06/30/what-goes-around-comes-around-and-around/
We have discussed it about 2 and half hours at our last meeting SIGMOD-Moscow
They overview RDF and graph DB, but not OWL.

Alex

пн, 30 дек. 2024 г. в 22:16, Michael DeBellis <mdebe...@gmail.com>:

Kingsley Idehen

unread,
Dec 31, 2024, 10:36:05 AM12/31/24
to ontolo...@googlegroups.com

Hi Paul and other interested parties,

On 12/30/24 2:44 PM, Paul Tyson wrote:


On 12/30/24 13:33, deddy wrote:
Michael -

Most of the methodologies and guidelines I've seen for building 
ontologies present the ontology as a thing in itself.

That is a realistic definition / description I can live with.


Fifteen years ago I one-on-one asked Jim Hendler if there were anything in "the SemWeb stack" for operational, legacy systems.... his instant response was an emphatic "No!"

2024 - P15Y = 2009 < 2012 (date of R2RML recommendation)

Best,
--Paul

Yes, R2RML is the component of “the SemWeb stack” designed to describe how relations in a DBMS are represented as relations in RDF.  

Here’s a post I wrote years ago, complete with live examples, demonstrating how to create an RDF-based Entity Relationship Graph from CSV files located on a local filesystem accessible to a Virtuoso instance:  

Virtuoso is a multi-model database management system in one of its guises. Specifically, it can operate on relations represented in the coarse-grained form typical of SQL-based DBMSs or in the finer-grained form facilitated by RDF via its Quad Store functionality.  

In my view, Ontology and Data Model are different terms for the same concept—they’re essentially conceptual synonyms. That said, practitioners often view them differently depending on their operational lenses. For example, most ontologists express their worldviews on data modeling using formal graphic or linear notations, while data modelers (often from the RDBMS domain) favor graphical notations such as ERD (Entity-Relationship Diagrams) or UML (Unified Modeling Language) diagrams.  

Links:

[1] Virtuoso How-To: Generating Linked Data from CSV Version of Northwind Database  
— A comprehensive guide demonstrating how to map relations in a CSV document to RDF and deploy them using Linked Data Principles (leveraging hyperlinks as super-keys).  

[2] Example Hyperlink Super-Key  
— A hyperlink-based super-key resolving to a specific row in a CSV document (which could also represent any ODBC- or JDBC-accessible table in an RDBMS).  

[3] Visualization of Entity Relationship Graphs  
— A visualization showcasing various aspects of an entity relationship graph constructed using Linked Data Principles.   

-- 
Happy New Year!

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com

Mike Peters

unread,
Dec 31, 2024, 6:24:14 PM12/31/24
to ontolog-forum
So, what options are there to map RDF to relational data?

Mike

Michael DeBellis

unread,
Dec 31, 2024, 8:55:29 PM12/31/24
to ontolo...@googlegroups.com

So, what options are there to map RDF to relational data?

I was going to list what little I knew but I'm working with ChatGPT right now, so I asked it. Here's what it said:

Implementing OWL (Web Ontology Language) in a relational database involves translating OWL's semantic capabilities into a relational schema and querying framework. 

Several tools and approaches allow you to achieve this:

Tools and Frameworks for OWL in Relational Databases

  1. RDF and SPARQL Layers on Relational Databases

    • Apache Jena with RDBMS Integration:

      • Jena provides a framework to work with RDF and OWL.
      • It supports relational database backends via the TDB or RDB storage layers.
      • You can map RDF triples to relational tables and query them using SPARQL.
    • Virtuoso Universal Server:

      • Virtuoso supports RDF storage and SPARQL queries directly in a relational database.
      • It combines a traditional RDBMS with a semantic store.
      • Useful for large-scale ontologies.
    • D2RQ:

      • A tool for exposing relational databases as virtual RDF graphs.
      • You can use OWL over the RDF representation while keeping data in the relational schema.
  2. Ontology Mapping Tools

    • Ontop:

      • A powerful tool to map OWL ontologies to relational databases using OBDA (Ontology-Based Data Access).
      • Allows you to query relational data through SPARQL while maintaining OWL semantics.
      • Supports mappings through R2RML or native Ontop mapping syntax.
    • Karma:

      • A tool for integrating data from relational databases with OWL ontologies.
      • Supports mapping relational data to RDF and OWL constructs.
  3. Hybrid Database Systems

    • GraphDB (by Ontotext):

      • A triplestore that can integrate with relational databases.
      • It allows you to store and query OWL data seamlessly alongside relational data.
    • Oracle RDF Graph:

      • Part of Oracle Database, it supports RDF and OWL data alongside relational data.
      • Provides SPARQL querying and reasoning capabilities.
  4. Custom Implementation Approaches

    • Mapping OWL Axioms to Relational Rules:

      • Use SQL views or stored procedures to encode OWL semantics manually.
      • Define mappings for classes, properties, and relationships in relational terms.
    • DL-Lite Ontology Mapping:

      • If your OWL usage aligns with OWL 2 QL (a subset of OWL optimized for relational databases), you can use DL-Lite mappings for efficient querying.

Considerations for Choosing a Tool

  1. Scale of the Ontology:

    • Large ontologies benefit from systems like Virtuoso or GraphDB, which are optimized for scalability.
  2. OWL Subset:

    • OWL 2 QL is specifically designed for integration with relational databases. Tools like Ontop are excellent for such use cases.
  3. Querying Needs:

    • If SPARQL is a requirement, tools like Ontop, Jena, or Virtuoso are natural fits.
    • For simple SQL querying, D2RQ or custom mapping may suffice.
  4. Reasoning Capabilities:

    • If you require reasoning over OWL axioms, focus on tools like GraphDB, Oracle RDF Graph, or Jena.

Suggested Approach

If you're starting out and want robust OWL support with minimal setup, Ontop is highly recommended. It supports direct integration with relational databases, enables SPARQL querying, and is well-documented.

Would you like a walkthrough on setting up any of these tools, or a comparison of their features?


--
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/RL97zvkBBMg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ontolog-foru...@googlegroups.com.
Message has been deleted

Elisa Kendall

unread,
Jan 1, 2025, 12:29:01 AMJan 1
to ontolo...@googlegroups.com

Hi Michael and all,

 

Together with other colleagues, we’ve used a number of the tools listed for mapping FIBO to relational for large banks successfully, including Ontop and Jena tools, among others. FIBO does include axioms, particularly some cardinality restrictions, that are outside of OWL RL, but most of the semantics can be mapped without any issues. RDFOx supports OWL RL, which is more expressive than OWL QL, and ignores anything outside of the RL profile rather than throwing up on it. Their team has also provided some rules that extended OWL RL for us to test with, including approximations of the axioms in FIBO that are outside of RL, which worked well. Stardog supports all of the semantics encoded in FIBO, and most knowledge graph tools that support SPARQL 1.1 can import it, though they may not support all of the reasoning encoded in the ontologies.

 

RDFOx and some other knowledge graph engines prefer either Turtle or JSON-LD to RDF/XML, which is the serialization we work in (primarily to see all of the warts in what we are publishing). But FIBO and the other ontology efforts I participate in publish in all three serializations – RDF/XML, Turtle, and JSON-LD, so that we can supply whatever is needed to a given tool/framework. Same is true of the Commons, MVF, LCC, and other ontologies we publish at OMG - in RDF/XML and Turtle, at a minimum. There is also a toolkit available from the EDM Council that we use to support transformations between serializations consistently, that we use for GitHub comparisons as well as for tool support, which we publish as open source at https://github.com/edmcouncil/rdf-toolkit. It’s a fairly complex Swiss army knife, with various options you can use to manage the transformation as needed.

 

Hope this is useful,

 

Elisa

 

From: ontolo...@googlegroups.com <ontolo...@googlegroups.com> On Behalf Of Michael DeBellis
Sent: Tuesday, December 31, 2024 5:55 PM
To: ontolo...@googlegroups.com
Subject: Re: [External] Re: [ontolog-forum] Re: Design Pattern Ontology

 

So, what options are there to map RDF to relational data?

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/CALGFikcMhKepLPVvfwmavoEv3LjnJVKoj5bifhi1K4ueng76AQ%40mail.gmail.com.

Alex Shkotin

unread,
Jan 2, 2025, 4:23:30 AMJan 2
to ontolo...@googlegroups.com
David: "The distinction / difference between data models & ontologies is what...?"
Universal reasoning algorithms, like tableau.

Alex

Kingsley Idehen

unread,
Jan 2, 2025, 11:44:13 AMJan 2
to ontolo...@googlegroups.com

Hi Mike,

On 12/31/24 6:24 PM, Mike Peters wrote:
So, what options are there to map RDF to relational data?

Mike

Do you mean the reverse—creating SQL RDBMS relations from RDF-based relations? If so, note that the SPARQL query language includes a SELECT option for projecting query solutions as tables from RDF Graphs, which can then be fed into a SQL RDBMS.

Kingsley


--
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/8f602f70-0bbb-4be8-abcf-39aa74d5f2ecn%40googlegroups.com.


-- 
Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software   
Home Page: http://www.openlinksw.com

Mike Peters

unread,
Jan 2, 2025, 12:53:45 PMJan 2
to ontolo...@googlegroups.com
Hi Kingsley

Yes, I do mean importing ontologies into relational databases. I'm not an oncologist, but I can see the great value in using ontologies, schema and taxonomies as read-only references in a working database.

The question is how to reliably and effectively allow users to point at any ontology using a form (e.g., something on OBO Foundry or SnowMed) and import it into the relational database they are logged into.

I was thinking OWL and RDF. Are both possible?

Mike

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/RL97zvkBBMg/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/fbcb2581-bf4d-486f-8af3-658bd626ee8a%40openlinksw.com.

Michael DeBellis

unread,
Jan 2, 2025, 1:17:02 PMJan 2
to ontolo...@googlegroups.com
I was thinking OWL and RDF. Are both possible?

As someone rightly pointed out in response to one of my answers, OWL is a logical, not a graph model, and not necessarily tied to RDF.  Since OWL is a subset of First  Order Logic (Description Logic) it can directly map to a relational database rather than going through RDF first. According to ChatGPT: 

Ontop Supports mappings through R2RML or native Ontop mapping syntax.
 
Michael

Mike Bennett

unread,
Jan 2, 2025, 3:24:54 PMJan 2
to ontolo...@googlegroups.com

Well this has been a very interesting sub-thread. I'll fork here from before the sub-thread on RDF to RDB etc. considerations.

Is "Ontology" really synonymous with, or even necessarily a kind of, "Data Model"?

I'd say emphatically not. There are kinds of ontology that are a kind of data model, of course, and much has been said about these in this sub-thread.

But those are not the only things of which it can be said "This is an ontology".

Any model has an "aboutness"; that is, "Of what is this a model"

For some models, what it is about is data: each element of the model represents some element of data.

For some models, the aboutness is that of things in the world.

The model language or formalism, and the model aboutness, are orthogonal: it does not necessarily follow that a model in a given language must be about a given kind of thing. UML Class models are designed to represent Object Oriented class constructs (with both behavioral and structural elements), but some people use them to represent all sorts of other things (including sometimes, things in the world). Similarly, an OWL model may represent RDF data and usually does, since that is what it is intended for.

Suppose someone wants to have a model of real things in the world. One would call this an "Ontology". However, as  soon as someone says they want an ontology, various people pop up and say "I can do you an ontology" when what they mean, as evidenced in this thread, is "I can do you an ontology of the sort that is a kind of data model".

Maybe that's what the customer needed, maybe it's not. If the business needs something that formally defines the meanings of things, for example for management communication, reporting, common understandings (in place of word-dependent dictionaries or glossaries) and so on, or if they want something for AI to process, then the chances are they need an ontology of the sort that represents real things in the world. All too often they get given an Ontology-as-data-model because someone thinks that is the only sort of ontology there is.

There are some questions, the answer to which is not a data model.

Let's consider 2 things:

1. Basic engineering best practice

2. Practical examples of how these kinds of ontology are different.

Good engineering follows a separation of concerns. Artifacts that represent the customer or business view, for example defining what the customer wants or what their world looks like, should always be expressed independently of any assumptions about the design techniques or technologies that will be used in crafting a solution. 

For example a business process model represents the activities that the business carries out, independently of any software design to automate these.

The reason is that (a) things are represented without presuming anything about the solution and (b) the solution can then be validated against that design-independend artifact. That's basic QA. 

Similarly, a data model is a kind of design (typically done at 2 levels: Platform Independent and Platform Specific, both of which are still designs).

The corresponding design-independent artifact is a kind of ontology: one in which the real-world meanings of the things of interest to the business are expressed. In other words, what does it mean to be this kind of thing?

Traditionally that's been done with words. But words are slippery. Better to use formal logic.

So there are ontologies which are a kind of data model, and there are ontologies which are a representation of things in the world. Both are needed, at these different levels in the development method, and with linkages between them.

A practical example of the difference is the best way to understand this distinction between these kinds of ontology.

And the difference is best illustrated with an example of where it went wrong.

The difference is between what we call "Truth Makers" and data. Truth Makers are what it takes for something to be defined as being a member of a given class of Thing. These are the necessary and sufficient conditions for a thing in the world to be a member of that class. Most of these are either physical matters such as physics and chemistry, or legal and social constructs such as legal capacities, value and so on (mainly classifiable under Searle's Ontology of Social Constructs - an ontology which is definitely not a data model; it's a book). A very few things get their meaning from data itself, as a kind of thing.

An ontology of things in the world (let's call this a Concept Ontology) defines things using those truth makers.

An ontology as a kind of data model looks for data surrogates for those things in the world: what data can you expect to find when this or that legal capacity, physical quantity value etc. is in play?

Example: suppose we consider what it means to be a bank. Very loosely, this is something with certain legal capacities, such as the capacity to take on funds, the capacity to disburse those funds and so on.

In one project I was involved with, the class "Bank" was defined using a data element for "FDIC Insurance", a kind of insurance that all banks in the US must carry. Then it was noticed that the DTCC, a clearing house, also carries FDIC Insurance, and so a different data item was sought instead.

There were two errors, one inside the other. The first, proximate error was that they chose the wrong data surrogate. The error inside the error (the ultimate error) was that they did not realize they were making a design decision for a data surrogate. Therefore, that design decision was not peer reviewed and was only discovered later (costing time etc. to fix which is another reason we have separation of concerns).

The model was updated to use the more correct data surrogate of Banking License. This reliably exists whenever the legal capacities for something to be a bank exists, and doesn't when it doesn't.

Of course that would not work in all use cases: if the requirement was to detect when some entity was acting as a bank when it should not be, you would look for data about the entity's behavior instead. Different use cases may give rise to different data surrogate design decisions.

And that's why, while ontology-as-data-model is an extremely valuable kind of data model, the same kind of engineeering integrity should go into their design as into the design of anything else, including the provision of ontologies of the target domain subject matter (subject to scope), against which these can be designed, against which design decisions can be reviewed, and against which the end result can be tested.

Those are ontologies too. These ideally use formal logic because words are too slippery to be relied upon. But just because a concept ontology is framed using formal logic, does not make it a data model (logic has been around a lot longer than computational data).

Mike

--
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.

Mike Peters

unread,
Jan 2, 2025, 5:53:31 PMJan 2
to ontolog-forum
I have written up a summary of this fascinating and useful discussion on my engineering blog. So far, I have quoted John Sowa, William "Bill" Burkett, Mike Peters, Michael DeBellis, David Eddy, Paul Tyson, Igor Toujilov, Alex Shkotin, Kingsley Idehen, Elisa Kendell and Mike Bennett.


This will help me add Ontology Import to my large, long-running software project, Pipi 9.

Mike Peters
New Zealand

Alex Shkotin

unread,
Jan 3, 2025, 6:52:42 AMJan 3
to ontolo...@googlegroups.com

Mike,


Two kinds of ontologies is an interesting point. And for me it is crucial that DL ontology can keep data in ABox. What it keeps in TBox is knowledge - logic of this data. To keep in data information about real things we assign them an Object Identifier.


You remind me of Data models. Dionysios C. Tsichritzis, Frederick H. Lochovsky · 1982

Where they overview 3+4 data models. First three are classical: Relational, Network, and Hierarchical. And four after are ER, Binary, Semantic network, and Infological. 

I think Semantic network is a kind of ontology (formal of course).


And we began with Feature analysis of generalized DBMS. TR. CODASYL 1971

The overview of 10 systems including COBOL.


Alex



чт, 2 янв. 2025 г. в 23:24, Mike Bennett <mben...@hypercube.co.uk>:

Kingsley Idehen

unread,
Jan 3, 2025, 11:03:01 AMJan 3
to ontolo...@googlegroups.com

Hi Mike,

On 1/2/25 12:53 PM, Mike Peters wrote:
Hi Kingsley

Yes, I do mean importing ontologies into relational databases. I'm not an oncologist, but I can see the great value in using ontologies, schema and taxonomies as read-only references in a working database.

The question is how to reliably and effectively allow users to point at any ontology using a form (e.g., something on OBO Foundry or SnowMed) and import it into the relational database they are logged into.

I was thinking OWL and RDF. Are both possible?

Mike


You can use SPARQL SELECT, as I described against a collection of relations (comprising terms from both the RDF and OWL ontologies/vocabularies) to insert data into relations (colloquially referred to as tables) managed by an RDBMS.


Kingsley

John F Sowa

unread,
Jan 3, 2025, 4:07:51 PMJan 3
to ontolo...@googlegroups.com, CG
Igor, Mike, Bill, List,

As Yogi Berrra said, these discussions are "Deja vu all over again."

Re "No SQL":  The person who coined that term, rewrote it as Not Only SQL   The original SQL was designed for data that is best organized in a table.  The fact that other data might be better represented in other formats does not invalidate the use of tables for data that is naturally tabular.

Re tree structure in ontologies:   A  tree structure for the NAMES  of an ontology does NOT imply that the named data happens to be a tree.   Some of the data might be organized in a tree, but other data might be better organized in a table, list, vector, matrix, tensor, graph, multidimensional shapes, or combinations of all of them.

The following survey article was written about 40 years of developments from 1970 to 2010.  Some new methods have been invented since then, but 90% of the discussions are about new names for old ideas re-invented by people who didn't know the history.   I wrote the survey, but 95% of the links are to writings by other people;  https://jfsowa.com/ikl .

And by the way, I agree with Bill Burkett (on the list down below).  He is one of the people I collaborated with on various committees in the past many years.  We viewed the Deja Vu over and over and over.  That's one reason why I don't get excited by new names.

John
 


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

John F Sowa

unread,
Jan 3, 2025, 11:49:22 PMJan 3
to James Davenport, ontolog-forum
Michael Stonebraker was the person I was thinking of.  See. for example, https://dl.acm.org/doi/pdf/10.1145/1721654.1721659

You can also google "Stonebraker" and "not only sql".

John
 


From: "James Davenport" <mas...@bath.ac.uk>

“Re "No SQL":  The person who coined that term, rewrote it as Not Only SQL“ – do you have a reference for that?

I keep trying to explain that NoSQL doesn’t mean it’s immune to SQL injection.

James Davenport 



Alex Shkotin

unread,
Jan 4, 2025, 4:29:09 AMJan 4
to ontolo...@googlegroups.com
Hi Mike,

What is an idea to import ontology into RDB? Just to store it? Or to use it as a schema for RDB?
And if the first do you need to keep it structurally or just as a blob?  

Let me show an example.
If we need to check that DB is consistent with ontology we need to convert DB to ABox of the GENO and start a reasoner.
Give your use case.

Alex

чт, 2 янв. 2025 г. в 20:53, Mike Peters <mi...@redworks.co.nz>:

Mike Peters

unread,
Jan 4, 2025, 4:37:59 PMJan 4
to ontolog-forum
Hi Alex

The idea is to feed Pipi 9 structured data from versioned external references, such as ontologies, taxonomies, XML Schemas, CSV, etc.

This data then becomes bits of relational database schema or is used to populate the tables.

This needs to be an automated process that is highly reliable. It's like using an external API.

So, using a silly made-up example of what I want to end up with.

Ontology-Imports-Table
----------------------------------
ID | Source | Version | Thing 1 | Relation | Thing 2
1 | obofoundary-example.owl | 5 | elf | worksFor | Santa
2 | obofoundary-example.owl | 5 | rudolf | isA | Reindeer
3 | obofoundary-example.owl | 5 | mary | isA | Elf
4 | obofoundary-example.owl | 6 | mary | isA | RetiredElf
5 | obofoundary-peridicTable.rdf | 1 | Plutonium | isA | Chemical Element
6 | movieLab.rdf | 5 | Camera | hasA | Camera Lens
7| movieLab.xml | 10 | DSMC2 Gemini 5K S35 | isA | Camera

Depending on user requirements, this could be used to generate;

Camera-Table
Camera-Lens-Table
ChemicalElement-Table
etc

Or

Populate a table with read-only records.

Mike

Alex Shkotin

unread,
Jan 5, 2025, 2:45:39 AMJan 5
to ontolo...@googlegroups.com
Mike,

I got it. You need to keep information about ontologies in RDB.
Why not ontology about ontologies like discussed here https://forum.solidproject.org/t/is-there-an-ontology-for-ontologies/2810

Alex

вс, 5 янв. 2025 г. в 00:38, Mike Peters <mi...@redworks.co.nz>:

Kingsley Idehen

unread,
Jan 5, 2025, 3:00:31 PMJan 5
to ontolo...@googlegroups.com

Hi John,

These days its just a simply prompt sent to the likes of Perplexity AI as per:

https://www.perplexity.ai/search/tell-me-about-stonebraker-and-v1M8TpHbTvSHlU6kml0TGg

Or even ChatGPT as per:

https://chatgpt.com/share/677ae3fb-afd0-8011-a37e-333dd8538975

Dump from ChatGPT.

Certainly! Below is the information about Michael Stonebraker and “Not Only SQL” (NoSQL) with relevant entities hyperlinked to their DBpedia IDs or Wikipedia pages where DBpedia links are unavailable.


Michael Stonebraker

  • Who is he?
    Michael Stonebraker is a Turing Award-winning computer scientist known for his foundational contributions to database systems. He played a key role in developing several pioneering database systems, including:

    • Ingres: One of the earliest relational database management systems (RDBMS).
    • PostgreSQL: An advanced object-relational database system.
    • Vertica: A columnar database optimized for analytical workloads.
    • C-Store: A research prototype that inspired Vertica.
    • H-Store: A main-memory distributed database that led to VoltDB.
    • SciDB: A database designed for complex scientific data.
  • Key Contributions:

    • Advocate for specialized database systems tailored to specific use cases (e.g., OLTP, OLAP, scientific data).
    • Vocal critic of “one-size-fits-all” database architectures, highlighting inefficiencies in applying traditional relational models to all workloads.

“Not Only SQL” (NoSQL)

  • What is it?
    NoSQL refers to a family of non-relational databases designed for scalability, flexibility, and performance in use cases where traditional RDBMSs fall short. The term “Not Only SQL” emphasizes that these systems do not exclusively use SQL or the relational model.

  • Key Characteristics of NoSQL:

    • Schema-less or flexible schema.
    • Horizontal scaling (e.g., distributed databases).
    • Optimized for unstructured, semi-structured, or poly-structured data.
    • Use cases often include web-scale applications, big data analytics, and real-time data processing.
  • Popular NoSQL Databases:


Stonebraker’s Perspective on NoSQL

  • Critique of NoSQL:
    Michael Stonebraker has been critical of NoSQL systems, particularly their lack of standardization, consistency guarantees, and durability in some implementations.

    • He argues that SQL systems can evolve to meet modern demands without abandoning decades of database research on ACID properties and consistency.
    • His work with systems like Vertica and VoltDB showcases that traditional SQL databases, when optimized, can outperform NoSQL systems for certain workloads.
  • Support for Specialized Systems:
    While skeptical of NoSQL as a panacea, Stonebraker advocates for “one size does not fit all” in databases. He believes the right database architecture depends on the specific workload:

    • SQL for OLTP and OLAP.
    • Columnar systems for analytics.
    • Distributed and in-memory systems for real-time processing.
    • Graph databases for relationship-heavy workloads.

The Bigger Picture

The “Stonebraker vs. NoSQL” narrative reflects a broader debate in the database world:

  1. Relational vs. Non-Relational: Relational systems excel at structured data, while NoSQL systems are designed for flexibility and scalability.
  2. The Rise of Polyglot Persistence: Modern applications often combine multiple database types (e.g., relational for transactions, NoSQL for analytics, graph for relationships).
  3. Convergence of Features: Over time, SQL and NoSQL systems have borrowed features from each other:
    • NoSQL systems are adding SQL-like query capabilities (e.g., SQL-like queries in MongoDB).
    • SQL systems are adopting features like horizontal scaling and schema flexibility.

Takeaways

  • Michael Stonebraker’s advocacy for specialized databases aligns with the ethos of NoSQL, even though he critiques its marketing and some implementations.
  • The ongoing evolution of database systems emphasizes choosing the right tool for the job rather than adhering dogmatically to one paradigm.
  • His work continues to influence the industry, bridging the gap between traditional RDBMSs and modern data needs.

Happy New Year!

Kingsley


--
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.

John F Sowa

unread,
Jan 6, 2025, 8:15:08 PMJan 6
to ontolo...@googlegroups.com
Kingsley,

Thanks for the information.  But note that it does not say who originally introduced the term "not only sql".  I had been following Stonebraker's work years ago (late 1980s and early 1990s).  That's why I was thinking of him..

He was definitely not an advocate of SQL, which he called "Intergalactic Dataspeak".   I was also very opposed to the SQL notation, which is far worse than the INGRES notation designed by Stonebraker and his colleagues.  I say this even though I was working at IBM at the time.

In any case, the data you found is quite good, but it does not answer the question of who invented the term "Not Only SQL",  Since Stonebraker did design a relational DB, he wasn't opposed to relations when they are useful.  But he also designed PostgreSQL, which supports relations and other kinds of DBs.  See, for example, https://thenewstack.io/dr-michael-stonebraker-a-short-history-of-database-systems/ .

Since  PostgreSQL supports relational as well as other systems, it can be said to be a kind of "Not Only SQL".  I also searched for the phrase "Not Only SQL" and got many hits, but they were fairly recent.  I couldn't find who was the first to introduce that term.

That implies that Stonebraker supported the idea of "Not Only SQL", but it does not mean that he himself actually said "Not Only SQL".

Can you use any of those systems to determine who first said or wrote "Not Only SQL"?

John
 


From: "Kingsley Idehen' via ontolog-forum" <ontolo...@googlegroups.com>

alex.shkotin

unread,
Jan 7, 2025, 4:19:30 AMJan 7
to ontolog-forum
John,

I asked SIGMOD-M community and Gemini. The Gemini answer is here: "The term "NoSQL" was first used by Carlo Strozzi in 1998 to name his lightweight, open-source "relational" database that did not use SQL.1

However, the term gained wider recognition in 2009 when Eric Evans and Johan Oskarsson used it to describe non-relational databases.2

While there's no single definitive source for the "Not Only SQL" interpretation, it became a common and accepted way to understand the acronym.3"

Alex


вторник, 7 января 2025 г. в 04:15:08 UTC+3, John F Sowa:

Harold Goranson

unread,
Jan 7, 2025, 4:28:54 AMJan 7
to ontolo...@googlegroups.com
I recall Damien Katz, circa 2006, using the term for Couch.

-- 
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.

Kingsley Idehen

unread,
Jan 7, 2025, 9:18:58 AMJan 7
to ontolo...@googlegroups.com

Hi John,

On 1/6/25 8:14 PM, John F Sowa wrote:

Kingsley,

Thanks for the information.  But note that it does not say who originally introduced the term "not only sql".  I had been following Stonebraker's work years ago (late 1980s and early 1990s).  That's why I was thinking of him..

He was definitely not an advocate of SQL, which he called "Intergalactic Dataspeak".   I was also very opposed to the SQL notation, which is far worse than the INGRES notation designed by Stonebraker and his colleagues.  I say this even though I was working at IBM at the time.

In any case, the data you found is quite good, but it does not answer the question of who invented the term "Not Only SQL",  Since Stonebraker did design a relational DB, he wasn't opposed to relations when they are useful.  But he also designed PostgreSQL, which supports relations and other kinds of DBs.  See, for example, https://thenewstack.io/dr-michael-stonebraker-a-short-history-of-database-systems/ .

Since  PostgreSQL supports relational as well as other systems, it can be said to be a kind of "Not Only SQL".  I also searched for the phrase "Not Only SQL" and got many hits, but they were fairly recent.  I couldn't find who was the first to introduce that term.

That implies that Stonebraker supported the idea of "Not Only SQL", but it does not mean that he himself actually said "Not Only SQL".

Can you use any of those systems to determine who first said or wrote "Not Only SQL"?

John

Courtesy of Perplexity AI:

The phrase “Not Only SQL” as an interpretation of NoSQL was not coined by a single individual, but rather emerged as a reinterpretation of the term within the database community. However, we can trace the evolution of this interpretation:

  1. The term “NoSQL” was originally coined by Carlo Strozzi in 1998 for his open-source relational database that did not use SQL[1][3].

  2. In 2009, Johan Oskarsson reintroduced the term “NoSQL” to describe non-relational, distributed databases[1].

  3. The interpretation of NoSQL as “Not Only SQL” gained popularity as the NoSQL movement evolved. This interpretation became widespread in the database community, but there’s no specific attribution to a single person for this reinterpretation[2][3].

The “Not Only SQL” interpretation emerged as a way to emphasize that NoSQL databases were not meant to completely replace SQL databases, but rather to complement them and provide additional options for data storage and retrieval[5].

Citations:
[1] https://en.wikipedia.org/wiki/Nosql
[2] https://hardware.slashdot.org/story/24/05/12/035214/father-of-sql-says-yes-to-nosql
[3] https://martinfowler.com/bliki/NosqlDefinition.html
[4] https://www.dataversity.net/a-brief-history-of-non-relational-databases/
[5] https://dba.stackexchange.com/questions/287383/if-nosql-stands-for-not-only-sql-is-sql-a-subset-of-nosql
[6] https://www.linkedin.com/posts/nithya-krishnan-a760187_sql-co-creator-embraces-nosql-activity-7196131390600413185-nxd3

Prof. Stonebraker made the “Not Only SQL” phrase mainstream, primarily. Personally, NoSQL is just a moniker for repudiating conflation of SQL and Relational Data Management.

Kingsley

--
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.

Michael DeBellis

unread,
Jan 7, 2025, 12:02:28 PMJan 7
to ontolo...@googlegroups.com
IMO, a much more interesting question than word etymology is why did people invent NoSQL and how is it being used today? Is there a bigger role that semantic technology could be playing in the space of corporate OLAP systems? The more I read about things like Data Lakes, Data Lakehouses, Data Catalogs, Data Mesh, and Data Fabric two things seem clear to me: 

1) Technologies like OWL and SHACL could be playing a much bigger role in this space than they currently do and based on the things that authors of these books value: (semantics, modeling metadata, flexibility of schema definition) OWL/SHACL should be playing more of a role.
2) All these technologies are at what people sometimes call an "inflection point" due to LLMs. I.e., architectures that people take for granted as state of the art no longer are due to LLMs and this is an opportunity for someone to create a new infrastructure for OLAP of large organizational data. For example, I just read a book about Enterprise Data Catalogs. The author had a whole section of the book (not one chapter but several chapters) devoted to search and as I read those sections I started skimming over them because I kept realizing that they were now essentially out of date. I messaged the author on LinkedIn and asked him what I thought was a rather provocative question: "Loved your Data Catalog book but isn't all the search stuff kind of obsolete due to LLMs?"  He answered with a resounding "yes!" (as well as a plug for his new book that is going to address this question of how to best exploit LLMs with data catalogs).

Actually, one third thing: when the question of a graph database comes up in this context it is almost always referring to Neo4j. E.g., many of the most commonly used tools for Big Data (Hadoop, Spark, Flink, Airflow) have native support for Neo4J graphs or already have connectors defined for them but not OWL/RDF. Here is some specific  info via ChatGPT:

Apache Hadoop: Hadoop doesn't have native support for RDF/OWL but works with Neo4j through plugins like Hadoop Connector for Neo4j. This integration allows large-scale batch processing and graph data export/import between Hadoop's HDFS and Neo4j.
Apache Spark: Spark has GraphFrames and GraphX libraries for graph processing, which can be used with Neo4j.
Tools like Neo4j Connector for Apache Spark enable seamless data exchange and graph analysis on Spark.
Apache Flink: Flink does not have built-in RDF/OWL support but works with Neo4j via tools like Flink-Graph or custom connectors. This integration allows stream processing of graph data stored in Neo4j.
Apache Airflow: Airflow workflows can orchestrate Neo4j graph queries and updates, especially through Python-based hooks and operators available in packages like Airflow-Provider-Neo4j.

Except for Airflow, it seems to me that semantic models have as much to offer in the OLAP space as property graphs due to the reasoners in OWL and SHACL. The reason I think Airflow is a special case is it represents workflows as Directed Acyclic Graphs (DAGs) and the property graph model where you have explicit representations of links rather than have them be implicit as values of binary relations or a reified class is a better fit for this. 

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/RL97zvkBBMg/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/7076b9b4-1f4e-48e5-b0b4-26601010ded5%40openlinksw.com.

Kingsley Idehen

unread,
Jan 7, 2025, 12:56:12 PMJan 7
to ontolo...@googlegroups.com

Hi Michael,

On 1/7/25 12:02 PM, Michael DeBellis wrote:
IMO, a much more interesting question than word etymology is why did people invent NoSQL and how is it being used today?


It seems the goal was to challenge the conflation of SQL, relations, and relational data management. Unfortunately, this has only led to further confusion.

The original sin remains: conflating SQL and relations due to the nature of relational database management systems as they evolved from Codd’s foundational work.

Prof. Stonebraker promoted QUEL as an alternative declarative query language for operating on relations, but it couldn’t overcome the momentum of DB2 and Oracle.

Today, SPARQL can be viewed as an enhanced evolution of what QUEL sought to achieve—at least, in my opinion. I’ve successfully used it to provide rich context across virtualized data spaces (encompassing databases, knowledge bases or graphs, and document collections) to support retrieval-augmented generation workflows. These workflows help minimize the ill-effects of hallucinations when using LLMs to integrate conversational interactions into data access and querying processes.


Is there a bigger role that semantic technology could be playing in the space of corporate OLAP systems? The more I read about things like Data Lakes, Data Lakehouses, Data Catalogs, Data Mesh, and Data Fabric two things seem clear to me: 

1) Technologies like OWL and SHACL could be playing a much bigger role in this space than they currently do and based on the things that authors of these books value: (semantics, modeling metadata, flexibility of schema definition) OWL/SHACL should be playing more of a role.
2) All these technologies are at what people sometimes call an "inflection point" due to LLMs. I.e., architectures that people take for granted as state of the art no longer are due to LLMs and this is an opportunity for someone to create a new infrastructure for OLAP of large organizational data. For example, I just read a book about Enterprise Data Catalogs. The author had a whole section of the book (not one chapter but several chapters) devoted to search and as I read those sections I started skimming over them because I kept realizing that they were now essentially out of date. I messaged the author on LinkedIn and asked him what I thought was a rather provocative question: "Loved your Data Catalog book but isn't all the search stuff kind of obsolete due to LLMs?"  He answered with a resounding "yes!" (as well as a plug for his new book that is going to address this question of how to best exploit LLMs with data catalogs).

Actually, one third thing: when the question of a graph database comes up in this context it is almost always referring to Neo4j. E.g., many of the most commonly used tools for Big Data (Hadoop, Spark, Flink, Airflow) have native support for Neo4J graphs or already have connectors defined for them but not OWL/RDF. Here is some specific  info via ChatGPT:

Apache Hadoop: Hadoop doesn't have native support for RDF/OWL but works with Neo4j through plugins like Hadoop Connector for Neo4j. This integration allows large-scale batch processing and graph data export/import between Hadoop's HDFS and Neo4j.
Apache Spark: Spark has GraphFrames and GraphX libraries for graph processing, which can be used with Neo4j.
Tools like Neo4j Connector for Apache Spark enable seamless data exchange and graph analysis on Spark.
Apache Flink: Flink does not have built-in RDF/OWL support but works with Neo4j via tools like Flink-Graph or custom connectors. This integration allows stream processing of graph data stored in Neo4j.
Apache Airflow: Airflow workflows can orchestrate Neo4j graph queries and updates, especially through Python-based hooks and operators available in packages like Airflow-Provider-Neo4j.

Except for Airflow, it seems to me that semantic models have as much to offer in the OLAP space as property graphs due to the reasoners in OWL and SHACL. The reason I think Airflow is a special case is it represents workflows as Directed Acyclic Graphs (DAGs) and the property graph model where you have explicit representations of links rather than have them be implicit as values of binary relations or a reified class is a better fit for this.


The entire data management landscape is a mess—primarily because the endgame always results in yet another silo, built from coarse-grained N-Tuple relations rather than finer-grained 3-Tuple relations.

Solution, IMHO?

Leverage the "Semantic Web Stack" with a focus on data de-silo-fication without getting into the buzzword bingo game re RDF, OWL, SHACL etc..

Hyperlinks as powerful super-keys is a magical solution, courtesy Linked Data Principles [1].

Links:

[1] https://www.linkedin.com/pulse/addressing-dbms-innovation-stagnation-hyperlinks-super-idehen-3fdae/ -- Addressing DBMS Innovation Stagnation with Hyperlinks as Super Keys

[2] https://medium.com/virtuoso-blog/conceptual-data-virtualization-for-sql-and-rdf-using-open-standards-24520925c7ce -- Conceptual Data Virtualization


Kingsley

Igor Toujilov

unread,
Jan 15, 2025, 4:30:29 PMJan 15
to ontolo...@googlegroups.com
Dear All,
I have started developing a design pattern ontology on GitHub:
https://github.com/itoujilov/design_pattern_ontology. This is my
initiative for an open source project. I do minimal atomic commits.
So, you can track the ontology development from scratch by small
steps.

Cheers,
Igor

On Sat, 21 Dec 2024 at 05:33, Michael DeBellis <mdebe...@gmail.com> wrote:
>
> Igor, to the best of my knowledge there isn't one and that is something I've thought would be good to build for quite a while. BTW, Martin Fowler also has a good book on Analysis patterns. I've also thought an ontology of refactoring and data pipeline transformations might be useful. Both to model patterns in general and for those that are specific to ontologies and knowledge graphs. Also, for refactoring of ontologies/knowledge graphs SPARQL combined with a programming language would be an excellent way to implement them. E.g., have Python functions like change_iri, splice_class, merge_classes, refactor_data_to_object_property,... When I worked on the Knowledge-Based Software Assistant (KBSA) program my team at Accenture and Lewis Johnson's team at ISI developed the idea of Evolution Transformations which were automated refactoring, just we focused on spec languages rather than programming languages. We met with Ralph Johnson and others to talk about how the ideas were similar and the OOP and formal methods KBSA groups could work together.
>
> I've always thought it would be a good idea to have a whole library of such refactoring transformations for knowledge graphs. Other examples would be transforming SWRL rules to SPARQL SPIN (much faster and many reasoners optimized for large graphs don't support SWRL). I was actually going to build that a while ago but then I did a search and someone beat me to it but I've never had a chance to try out his implementation. Also, transforming OWL restrictions to SHACL constraints. I've done this kind of thing countless times, actually in every ontology I've ever built that had to integrate with real data. Inevitably we would have OWL axioms like the datatype of some property must be xsd:decimal but the input data always had bad data so the ontology would never be consistent if it was getting regular updates from relational databases and other sources. We didn't use SHACL because it was easier to just remove the datatype restriction and use SPARQL to transform the bad data and then convert all the data to be the appropriate datatypes after cleaning the data. Of course another approach would be to clean the data before it gets into the knowledge graph but in my experience that tends to be difficult for other reasons. E.g., a lot of times to transform the data you need to use other data that was loaded. But I think the better way to do that might be to convert some axioms from OWL to SHACL. I know the dogma is "OWL is for reasoning and SHACL is for data restrictions" but in my experience the distinction isn't always so clear cut.
>
> Cheers,
> Michael
>
> On Monday, November 25, 2024 at 4:41:28 PM UTC-8 Igor Toujilov wrote:
>>
>> Hi All,
>> I am studying a famous book [1] written by the Gang of Four. I am
>> surprised that despite it being written 30 years ago, I did not find a
>> design pattern ontology. There is plenty of material on ontology
>> design patterns on the Internet, but nothing about a design pattern
>> ontology which I miss and want to create if it does not exist yet.
>> Please advise if I overlooked something.
>>
>> Regards,
>> Igor
>>
>> [1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design
>> patterns : elements of reusable object-oriented software. 1994.
>
> --
> 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/2a9c9c9b-dffa-4703-bedc-1c03cff05975n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages