GraphNews

6044 bookmarks
Custom sorting
Knowledge Graph for AI: Mapping Capabilities with Distilled AI Primitives
ontology modelling and semantic web learning resources
ontology modelling and semantic web learning resources
Hello, world! I wanted to take a few minutes to share this with my network, where there are both established and aspiring ontologists and knowledge graph engineers. During my pivot from linguistics and NLP toward ontology modelling and the semantic web, I found the following resources to be invaluable and I wanted to share them with the community: •Tish Chungoora, Ph.D.'s classes on Udemy: - https://lnkd.in/drhtwmNz (most interactive) • 28DIGITAL's course on Coursera: - https://lnkd.in/drv5taiy • openHPI courses provided by Harald Sack and his colleagues (also easily found on youtube as playlists) - https://lnkd.in/dmR6qjGG - knowledge graphs, foundations and applications - https://lnkd.in/diWk_-At - knowledge engineering with the semantic web • Bob DuCharme's blog and resources: - https://www.bobdc.com/ - https://lnkd.in/dkHTQwrs • Dean Allemang's book: - https://lnkd.in/d67dqJPf
ontology modelling and the semantic web
·linkedin.com·
ontology modelling and semantic web learning resources
ServiceNow is joining Open Semantic Interchange (OSI)
ServiceNow is joining Open Semantic Interchange (OSI)
ServiceNow is joining Open Semantic Interchange (OSI)! Sharing a few of my personal thoughts: 🟢 Three years ago at Snowflake Summit 2023, I was making the case that LLMs couldn’t just “figure out” the semantics of your business by giving the model training data, fine-tuning it, etc. And that is why we need to invest in semantics and knowledge graphs. The pushback was: show us the numbers. So we built the benchmark. Our research result was one of the first to rigorously demonstrate the accuracy gap between LLMs querying raw data versus LLMs equipped with an ontology and knowledge graph. That accuracy increase was 3X at that time. It helped wake up the industry to what knowledge graphs and ontologies actually bring to the table. 🟢 Across hundreds of recent customer conversations, I’m watching organizations realize that the semantics of your business, your definitions, your metrics, your processes, your decisions, are the DNA of your company. Frontier models don’t come with that. You have to give it to them. And if it’s not standardized from the start, you’re going to rebuild it over and over again. The vendor lock-in concern is real. 🟢 There are actually two different problems here, and people are conflating them. 1. Semantic interoperability as infrastructure. This is the work of defining your business concepts, metrics, processes, decision logic in a way that is open, interoperable, and machine-readable. It’s foundational. It’s about ensuring that when any system (AI or otherwise) touches your business data, operational or analytical, and it operates from the same shared understanding. 2. Semantic context for AI agents. AI agents need to understand the context of the business to act on your behalf. This is a powerful, urgent use case, and it’s creating the most powerful organizational incentive we’ve ever had to finally invest in semantics. Don’t confuse the consumer (AI agents) with the foundation (semantic interoperability). Both matter. My suggestion is to start small and think big with “Semantic interoperability as infrastructure” as the goal because “Semantic context for AI agents” will come with it. If you focus on the goal of AI agents first, then you are missing out and most probably end up building brittle systems. 🟢 If you’re just getting started: don’t try to model your enterprise on day one. Start with your data warehouse semantics, your metrics definitions, your BI layer. Build governance around it. Then expand. 🟢 Proud that the og data.world team’s work contributed to putting semantics in the spotlight, and now honored to now be contributing to OSI alongside so many great partners. 🟢 For those asking about how OSI relates to the broader semantic web and W3C standards (i.e. RDF/OWL/SHACL),  yes, that thread is coming. Is your investment in semantics for AI agent requirements, or are you thinking about it as broader semantic interoperability as infrastructure? Link to my substack and ServiceNow announcement blog | 38 comments on LinkedIn
·linkedin.com·
ServiceNow is joining Open Semantic Interchange (OSI)
Having your master data in RDF is often not an option and this is where a hazardous search for ETL/sync/materialization starts
Having your master data in RDF is often not an option and this is where a hazardous search for ETL/sync/materialization starts
Having your master data in RDF is often not an option and this is where a hazardous search for ETL/sync/materialization starts. I wrote before about YARRRML, maplib, RML, Morph-KG, LinkML and similar tools. Here I'd like to highlight the virtual graph approach: pulling SQL via SPARQL and turning Postgres into a triple store via extensions. pgRDF is a Rust-native Postgres extension built on pgrx that stores RDF as a dictionary-encoded hexastore. The benchmarks are unusually ambitious, SHACL validator and an OWL 2 RL reasoner. Quite impressive. The catch is the single dev and maturity of the project. Ontop is a popular and reliable option and has been integrated into GraphDB as a data virtualization solution. It's solid. Caveats live in some specific needs like heavy usage of OPTIONAL, aggregation heavy queries and highly dynamic data. rdf_fdw is a Postgres foreign data wrapper that enables seamless integration with RDF triplestores via SPARQL endpoints. It supports querying RDF data using SQL, somewhat like ontop. Here as well, I'd be careful with using a Github project that has not proven itself. The more enterprisey option involves messaging (Kafka) and workflows (Kestra, Prefect...) with the added advantage that it gives you a company-wide integration rather than a one-to-one pipeline. Plus, this works with other relational DBs, not just Postgres. Did I overlook a major/magical option? - pgRDF: https://lnkd.in/epXw6g2R - ontop: https://ontop-vkg.org - rdf_fdw: https://lnkd.in/ei8etVCQ #RDF #GraphDatabase #KnowledgeGraphs
Having your master data in RDF is often not an option and this is where a hazardous search for ETL/sync/materialization starts
·linkedin.com·
Having your master data in RDF is often not an option and this is where a hazardous search for ETL/sync/materialization starts
Kuzu post-mortem: ` I Analyzed 163k Lines of Kuzu’s Codebase. Here’s Why Apple Wanted It. `
Kuzu post-mortem: ` I Analyzed 163k Lines of Kuzu’s Codebase. Here’s Why Apple Wanted It. `
For those of us still wondering about the Kuzu post-mortem: ` I Analyzed 163k Lines of Kuzu’s Codebase. Here’s Why Apple Wanted It. ` tl;dr: Apple needed a graph database to make Apple Intelligence, you know...intelligent and on device. It's the same story we're seeing again and again: Throwing LLMs at something by themselves will result in slop, hallucinations, and silver-tongued vapors. Graph technology provides a backbone to knowledge, intelligence, and in Kuzu's case, a bit of wisdom. This article is obviously just the author's personal perspective. I'm happy to hear your take too. https://lnkd.in/gDvykhdS #graphdatabases #kuzu
Kuzu post-mortem: ` I Analyzed 163k Lines of Kuzu’s Codebase. Here’s Why Apple Wanted It. `
·linkedin.com·
Kuzu post-mortem: ` I Analyzed 163k Lines of Kuzu’s Codebase. Here’s Why Apple Wanted It. `
It seems like we're fast approaching a context hangover
It seems like we're fast approaching a context hangover
It seems like we're fast approaching a context hangover. The first half of the year, you couldnt attend a conference, login to LinkedIn, or browse a vendor website without being constantly bludgeoned with references to context. This is still the case, but the hype seems to be fading. Why? Because the idea of 'context' is too academic for most CDO's. Our discussions are too focused on the technicalities of things like ontologies and semantic layers. There's almost no focus on *why* these technologies are important, or what the business value of implementing them will be. The value of context is consistently expressed through capabilities, and not business outcomes. This only magnifies the confusion, and I suspect most are thoroughly exhausted by it. On the bright side, we're on the downslope of all the hype around context. The hangover is next. #context #semanticlayer #knowledgegraph | 47 comments on LinkedIn
It seems like we're fast approaching a context hangover
·linkedin.com·
It seems like we're fast approaching a context hangover
An ontology needs a way to evolve without pretending its past never existed.
An ontology needs a way to evolve without pretending its past never existed.
An ontology needs a way to evolve without pretending its past never existed. I’ve been working through this problem while designing lifecycle governance for semantic entities. The central distinction I keep returning to is: Unused is a signal. Obsolete is a governance decision. Usage data can help identify candidates for retirement: classes with no instances, properties nobody queries, or entities that no longer receive new relationships. But before deleting anything, we still need to ask: - Does historical data depend on it? - What relationships or downstream systems reference it? - Has another entity replaced it? - Would removing it erase part of the system’s semantic history? In many cases, the safer outcome is governed deprecation: - Remove the entity from the active semantic model - Prevent new relationships or uses - Preserve its historical relationships, provenance, and lineage - Identify what replaced it - Record why, when, and by whom it was deprecated This changes the architectural question. It is no longer simply, “Can this entity be deleted?” It becomes, “How can we simplify the active model without breaking dependencies or erasing the knowledge needed to interpret its history?” #SemanticEngineering #DataGovernance #AppliedOntology #KnowledgeGraphs #OntologyStudio
An ontology needs a way to evolve without pretending its past never existed.
·linkedin.com·
An ontology needs a way to evolve without pretending its past never existed.