- From: Sebastian Samaruga <ssamarug@gmail.com>
- Date: Sun, 12 Oct 2025 14:27:18 -0300
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: W3C Semantic Web IG <semantic-web@w3.org>, W3C AIKR CG <public-aikr@w3.org>, public-lod <public-lod@w3.org>
- Message-ID: <CAOLUXBvs9A0zFkgkO1VGKzXT6JKquSmphsEjWuYF4=uaNHPH+Q@mail.gmail.com>
Great! Seems like I'm in the right direction then. LLMs could do that and a bunch of other amazing stuff by their "massive brute force" approach that makes them seem "inteligent". However, what if we ease things for machines a little? Reifying addresses and links as resources on their own, contextually annotable, addressable and linkable, with HTTP / REST means of interaction for their browsing and (link) discovery, having developed a schema on which render the representations of those resources. That's a task in which LLMs could excel. Kind of "meta" AI task, call it "semantic indexing". Having this "Semantic Hypermedia Addressing" knowledge layer rendered, in RDF resources for example, it could be consumed further by LLMs Agents, given a well defined RAG or MCP tools interface, leveraging the augmented knowledge layer from the previous step. That if you're stuck with AI and LLMs "middleware" (think is better term than "browser" or "client"). Nothing prevents from having this knowledge layer used as a service on its own, with the appropriate APIs. The rest, use cases and applications, boils down to whatever is possibly imaginable. Each tool bearer ("hammer") will use it to solve every problem ("nail"). Think of "what applications can be done with graph databases". Nearly every tool (programming language) can be used to solve any problem or a part of it (layer) The question is choosing the right tool for the right layer of the problem. At a networking level, OSI defines seven layers: Application (Protocol), Presentation, Session, Transport, Network, Data Link, and Physical layers. That clean separation allowed us to have browsers, email clients and the internet we know today. MVC pattern and also the Semantic Web itself have a layered pattern layout. Once we know the right layers may we came with the right tools (that's why I said "middleware"). Note: I'm not discovering nothing new. I'm inspired by: ISO/HyTime (ISO/IEC 10744), ISO/TopicMaps (ISO/IEC 13250), ISO 15926 Regards, Sebastián. On Sun, Oct 12, 2025, 12:49 PM Kingsley Idehen <kidehen@openlinksw.com> wrote: > > On 10/11/25 10:53 AM, Sebastian Samaruga wrote: > > Another App for LLMs, REST and RDF. > > > > Semantic Hypermedia Addressing (SHA): > > > > Given Hypermedia Resources Content Types (REST): > > > > . Text > > . Images > > . Audio > > . Video > > . Tabular > > . Hierarchical > > . Graph > > (Am I missing something?) > > > > Imagine the possibility of not only annotate resources of those types > > with metadata and links (in the appropriate axes and occurrences > > context) but having those annotations and links being generated by > > inference and activation being that metadata and links in turn > > meaningful annotated with their meaning given its occurrence context > > in any given axis or relationship role (dimension). > > > > RESTful principles could apply rendering annotations and links as > > resources also, with their annotations and links, making them > > discoverable and browsable / query-able. Naming conventions for > > standard addressable resources could make browsing and returning > > results (for a query or prompt, for example) a machine-understandable > > task. > > > > Also, the task of constructing resources hyperlinked or embedding > > other resources in a content context (a report or dashboard, for > > example) or the frontend for a given resource driven (REST) resource > > contexts interactions will be a matter of discovery of the right > > resources and link resources. > > > > Given the appropriate resources, link resources and addressing, > > encoding a prompt / query for a link, in a given context (maybe > > embedded within the prompt / query) would be a matter of resource > > interaction, being the capabilities of what can be prompted / queried > > for available to the client for further exploration. > > > > Generated resources, in their corresponding Content Types, should also > > address and be further addressable in and by other resources, enabling > > incremental knowledge composition by means of preserving generated > > assets in a resources interaction contexts history. > > > > Examples: > > > > "Given this book, make an index with all the occurrences of this > > character and also provide links to the moments of those occurrences > > in the book's picture. Tell me which actor represented that character > > role". > > > > Best regards, > > Sebastián. > > > Hi Sebastian, > > "Imagine the possibility of not only annotate resources of those types > with metadata and links (in the appropriate axes and occurrences > context) but having those annotations and links being generated by > inference and activation being that metadata and links in turn > meaningful annotated with their meaning given its occurrence context in > any given axis or relationship role (dimension)." > > LLM-based AI Agents loosely coupled with RDF-based Knowledge Graphs > already do that. 🙂 > > In the latest edition of my LinkedIn newsletter [1], I dropped a post > that explores exactly this in action. It features a demo of a personal > assistant loosely coupled with my personal profile document—capable of > answering questions using Knowledge Graphs automatically constructed > from my notes. > > In essence, I’ve built a workflow that starts with documents that > capture my interest and culminates in SPARQL inserts into a live > Virtuoso instance containing a collection of note-derived Knowledge Graphs. > > Links: > > [1] From Web 2.0 to the Agentic Web: The Shift from Eyeballs to AI Agent > Presence -- > > https://www.linkedin.com/pulse/from-web-20-agentic-shift-eyeballs-ai-agent-presence-idehen-u9fne/ > > [2] The File Create, Save, and Share Paradigm (Revisited) -- > > https://www.linkedin.com/pulse/file-create-save-share-paradigm-revisited-kingsley-uyi-idehen-phxze > > > -- > 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 > > >
Received on Sunday, 12 October 2025 17:28:37 UTC