Semantic Hypermedia Addressing
Given Hypermedia Resources Content Types (REST):
. Text
. Images
. Audio
. Video
. Tabular
. Hierarchical
. Graph
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.
AI 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.
User generated resources: documents, images, audio, video and even mails, chats, calendars, meetings and meeting notes, for example, would leverage this semantic addressing and being semantically addressable capabilities. Even the interactions with (business) applications, such as the placement of an order, an ERP transaction or a CRM issue resolution, as addressing and addressable resources, will take part of this resource oriented linked knowledge network augmenting and being augmented with AI generated resources and addressing.
Wouldn't will be nice if our browsing history where arranged in a meaningful task and purpose oriented manner, organized in a way where it is possible to know where we are and why, how and from where did we get there?
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".
Of course, LLMs could do that and a bunch of other amazing stuff by their "massive brute force" approach that makes them seem "intelligent".
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").
Comments
Post a Comment