GraphNews

6121 bookmarks
Custom sorting
descriptive access as a requirement for engineering semantic systems.
descriptive access as a requirement for engineering semantic systems.
Context is still a nebulous concept that conveniently shape shifts. So as I work with clients, I am breaking down context according to types of context to help shape the conversations. Borrowing from library and information science, I have started introducing the idea of descriptive access as a requirement for engineering semantic systems. This is generally how an object is identified, discovered and retrieved and Descriptive access is retrieval through the description of a resource rather than through its aboutness — access points drawn from descriptive metadata (creator, title, date, form/genre, extent, identifier) as opposed to subjects or classification. It’s the “who/what/when” half of the catalog’s finding function; subject access is the “about” half. In the metadata-type taxonomy it’s the discovery-and-identification layer, distinct from administrative, structural, and preservation metadata. The relationship to context is constitutive rather than incidental — a descriptive value only becomes an access point when a context makes it resolvable. Authority control: “Smith, John” is a string until an authority record supplies dates, associated entities, and scope. The disambiguating context is what converts description into access. Provenance description: Provenance and original order mean the description is a statement of context. This can be achieved by replacing the single hierarchical context with a graph, so a record becomes accessible through any of its contexts — agent, activity, mandate, place, date — instead of only through its individual elements. Reference model: Reference Information supplies the identifiers and access points; Context Information documents why the content exists and how it relates to other information. Both sit inside PDI, which is a fairly explicit institutional admission that access degrades without context. SKOS and graph terms: prefLabel gets you the node; inScheme, broader/narrower, scopeNote, and mappings are the context that fixes what the node means. Strip them and you have lexical matching without semantics. You see this failing with embedding-only retrieval, where “context” gets redefined as adjacent tokens rather than as documented relationships. Context is what makes a descriptive value an access point instead of a string, and descriptive access is how context gets operationalized for retrieval. Context is a dangerous catch all that's built for convenience, not results.
descriptive access as a requirement for engineering semantic systems.
·linkedin.com·
descriptive access as a requirement for engineering semantic systems.
From Triples to Truth: Why SHACL Will Not Save Ontological Engineering | LinkedIn
From Triples to Truth: Why SHACL Will Not Save Ontological Engineering | LinkedIn
Note 1: A glossary is provided at the end of the article in order to decrypt the Ontology domain jargon ;) Note 2: This article is not intended to criticize SHACL as a technology or standard. SHACL plays an important and complementary role alongside OWL and Description Logics.
·linkedin.com·
From Triples to Truth: Why SHACL Will Not Save Ontological Engineering | LinkedIn
Ontology Development Suite A VS Code extension for creating ontologies (with owl:imports) and building TARQL-style CSV → RDF data graphs, with live diagnostics, a local SPARQL/SHACL/OWL2-RL checks engine, and DL-expressivity/OWL2-profile metrics
Ontology Development Suite A VS Code extension for creating ontologies (with owl:imports) and building TARQL-style CSV → RDF data graphs, with live diagnostics, a local SPARQL/SHACL/OWL2-RL checks engine, and DL-expressivity/OWL2-profile metrics
A Code extension for developing ontologies ... and a lot more besides - pwin/consolidated-ontology-quality-suite-webapp
Ontology Development Suite A VS Code extension for creating ontologies (with owl:imports) and building TARQL-style CSV → RDF data graphs, with live diagnostics, a local SPARQL/SHACL/OWL2-RL checks engine, and DL-expressivity/OWL2-profile metrics —
·github.com·
Ontology Development Suite A VS Code extension for creating ontologies (with owl:imports) and building TARQL-style CSV → RDF data graphs, with live diagnostics, a local SPARQL/SHACL/OWL2-RL checks engine, and DL-expressivity/OWL2-profile metrics
What is an Ontologist? Bridge Builders Edition
What is an Ontologist? Bridge Builders Edition
What is an ontologist is a top question I hear from folks, from those looking to break into the knowledge graph or symbolic AI space, or those trying to hire these folks. Join me and some of the wonderful ontology folks from Bloomberg in the latest in this mini-series. Sample job description from this chat: https://docs.google.com/document/d/1cBAUWZOSzwPpME_vpbv_VXrSd4mq9-j7DzlpOOMYzn8/edit?usp=sharing Note: all opinions are my own as a data scientist and researcher in the field and are not representative of the tool/company being reviewed, nor of any other company. Stay in touch: LinkedIn: https://www.linkedin.com/in/ashleighnfaith/ Direct Message: isadatathing-at-gmail.com
·youtube.com·
What is an Ontologist? Bridge Builders Edition
Ontology Management Wheel
Ontology Management Wheel
DAMA has guided us well in managing data. As we move into the AI era, Semantics and Ontology are carrying the torch for context and information quality. The next challenge is not just managing data, but managing meaning so information can be consistently understood by people, systems and AI. Here is my attempt at a comprehensive Ontology Management Wheel, outlining how organizations can systematically build, govern and operationalize semantics and ontologies. #Ontology #SemanticLayer #DataManagement #KnowledgeGraph #EnterpriseAI
Ontology Management Wheel
·linkedin.com·
Ontology Management Wheel
LARQL decompiles transformer models into a queryable format called a vindex (vector index), then provides LQL (Lazarus Query Language) to browse, edit, and recompile the model's knowledge.
LARQL decompiles transformer models into a queryable format called a vindex (vector index), then provides LQL (Lazarus Query Language) to browse, edit, and recompile the model's knowledge.
·github.com·
LARQL decompiles transformer models into a queryable format called a vindex (vector index), then provides LQL (Lazarus Query Language) to browse, edit, and recompile the model's knowledge.
Context-Aware Reasoning in Knowledge Graphs
Context-Aware Reasoning in Knowledge Graphs
When does a fact "here" becomes a fact "everywhere"? Every graphRAG or GNN pipeline answers this question implicitly, every time it aggregates neighbors into a node's representation (via message passing and pseudo-random walks). Almost none of them answer it on purpose. A recent paper puts a name to the missing piece: sheaf based semantics. Call it glueing. Think of a knowledge graph as a patchwork quilt. Each entity has local information stitched to it. The question is: can you sew these patches together into one consistent picture, or do the edges not actually line up? That's precisely what mathematicians call a sheaf. It's the formal machinery for stitching local pieces of information into a global whole, with a built-in check for when the stitching is actually valid not just averaged, but genuinely consistent. It's less geometric than fiber bundles (no connections or curvature) and more algebraic topology. The paper applies this to knowledge graphs in two steps. First, treat the graph as generating paths of reasoning, entity to entity, hop by hop. Standard stuff. Then, define two different rules for what counts as "enough local evidence" to draw a conclusion. One rule says: only trust exact matches, no propagation (purely local). The other says: trust information that flows along connected paths (contextual). These two rules produce two different and provably related notions of truth on the same graph. Why this matters for knowledge-augmented AI? It's a rigorous version of what GNN message-passing and multi-hop RAG are already trying to do from intuition. Different aggregation strategies, different "how far do I trust my neighbors" settings. If you pick up the article you will see that you need quite a bit of math maturity. Much like my post on categories and functors, this one is for connoisseurs 🍷 It also explains a failure mode a lot of practitioners have hit but rarely name, that dumping a knowledge graph into flat text for an LLM destroys exactly this stitching structure. Technically, a forgetful functor. You flatten the topology. There's no "quilt" left, just patches, which is why naive textualization quietly loses information that graph-native reasoning would have kept. What is the point of rephrasing technical things in math language? To go beyond and generalizes what is known, to see connections on a higher level. For myself, the momentum of the mind always points towards abstraction. #KnowledgeGraphs #GraphRAG #Semantics - Context-Aware Reasoning in Knowledge Graphs : https://lnkd.in/e5rmBAvX - Sheaves for AI: https://lnkd.in/eCbm4eQD
Context-Aware Reasoning in Knowledge Graphs
·linkedin.com·
Context-Aware Reasoning in Knowledge Graphs
open-ontologies: AI-native ontology engine: a Rust MCP server with tools for building, validating, querying, and reasoning over RDF/OWL ontologies. In-memory Oxigraph triple store, native OWL2-DL tableaux reasoner, SHACL validation, SPARQL, versioning. Single binary, no JVM.
open-ontologies: AI-native ontology engine: a Rust MCP server with tools for building, validating, querying, and reasoning over RDF/OWL ontologies. In-memory Oxigraph triple store, native OWL2-DL tableaux reasoner, SHACL validation, SPARQL, versioning. Single binary, no JVM.
·github.com·
open-ontologies: AI-native ontology engine: a Rust MCP server with tools for building, validating, querying, and reasoning over RDF/OWL ontologies. In-memory Oxigraph triple store, native OWL2-DL tableaux reasoner, SHACL validation, SPARQL, versioning. Single binary, no JVM.