In the age of agentic systems, correct autonomous data management is increasingly critical. Agents need to discover what resources exist and how to interact with them, but existing interface description frameworks that could provide such support either leave too much open to interpretation or fail to model underlying resources, which are not directly exposed. To address this gap, we propose a declarative description that describes underlying resources and their transformations by modeling interfaces as algebraic flows that declaratively define how underlying resources are exposed, derived, and manipulated. We detail our vision by walking through an example use case that showcases the various problems agents have when interacting with data interfaces and incrementally present our solution of modeling how data flows within the system. Our approach shows that interface developers can express their systems using familiar query languages, while enabling autonomous agents to reason about the consequences of actions and determine required operations to manipulate resources safely and predictably. This makes deterministic interactions with complex, asymmetric information interfaces possible. Looking ahead, we aim to formalize this approach into a theoretically sound framework with a proof-of-concept implementation. Additionally, we identify promising avenues for integrating policy-aware semantics and privacy-preserving interface disclosure.2
Throughout this paper we will use Fig. 1 as an example use case to motivate our approach. Our use case is an interface around a pet doctors database registering pet-owners and their pets. We include four endpoint families: 1. <post-owner>: registers a new owner and their pets in the system. 2. <change-owner>: transfers a pet from one registered owner to another. 3. <get-owners>: retrieves a list of URIs representing all registered owners. 4. <get-owner>: fetches an individual owner along with their associated pets + pet data. Important to note is that our system explicitly models the underlying <database> resource, meaning other systems can now reference the underlying resource ‘all owners and their pets registered in the system’, and deduce what endpoints manipulate and expose it.
This paper presents a vision for a future in which interfaces formally describe their underlying resources and how to manipulate them, creating rich, composable, and formal interface semantics. Our goal is to stimulate dis‐ cussion on how such descriptions can support autonomous operation, improve agent reliability, and pave the way for more interoperable and adaptive knowledge infrastructures. While the proposed direction remains con‐ ceptual, we offer initial ideas and mappings that illustrate how this approach could be realized in practice. In the next section we review related work, discussing various existing ways to describe data interfaces. In Section 3 we detail our vision, and we conclude our paper in Section 4.
Existing web interface description frameworks fall into several distinct families, each optimized for different us‐ age scenarios. However, most fall short in their ability to formally and completely describe how data flows from write operations to corresponding reads or how internal state transitions occur within the system, across endpoints.
RPC and Syntactic Interface Specifications - Remote Procedure Call (RPC) style specification languages such as WADL [8] and OpenAPI/Swagger [9] primarily offer syntactic descriptions of web APIs. These specifica‐ tions define endpoints, parameters, and payload schemas in formats like XML (WADL) or JSON/YAML (OpenAPI). Although they support URI templates [10] and detail input-output structures, they do not capture se‐ mantic relationships between operations, nor do they support hypermedia or model the consequences of state modifications. OpenAPI is widely used for generating documentation and client code, but it only supports syn‐ tactic interoperability, requiring human developers or intelligent stochastic agents to infer the meaning of operations.
Similarly, AsyncAPI [11] extends the RPC-style description model to event-based APIs, offering a syntax for defining message-driven architectures. It describes publish/subscribe channels, message schemas, and communi‐ cation protocols (e.g., MQTT, WebSocket), which makes it well-suited for heterogeneous environments. However, like OpenAPI, AsyncAPI lacks the ability to model how emitted messages impact application state. Messages are specified structurally, but not semantically; the relationship between an event and the resulting system state is left implicit.
Our solution will convey how the underlying resources are modified by describing the interaction between write operations, exposed resources and non-exposed resources (e.g. an underlying database).
Tool Invocation and Agent-Oriented APIs - The Model Context Protocol (MCP) [12] represents a newer class of interface which is self-descriptive and aimed at AI agent interoperability. Since MCP allows external tools to advertise available resources (readable data) and tools (invokable operations) to large language models (LLMs), enabling structured interaction via natural language, MCP could be used as a data interface. While this model does conceptually align reads and writes with corresponding resources and tools, it lacks formal semantics. Descriptions in MCP are purely textual, and while this enables flexible reasoning by LLMs, it does not guarantee unambiguous interpretations of system behavior or consequences of actions. As a result, agents cannot reliably infer the downstream effects of invoking a particular tool. The solution we present tackles the reliability problem by algebraically describing the relationship.
Semantic Web Descriptions - In the context of the Semantic Web, interface description languages aim to embed operational semantics into Linked Data. The Hydra Core Vocabulary [13] allows API providers to anno‐ tate resources with affordances - like descriptions of possible state transitions. This enables clients to discover valid actions dynamically through hypermedia controls. While Hydra provides an elegant model for describing RESTful interactions, it fundamentally assumes symmetry between inputs and outputs. It does not support asym‐ metric interfaces, for example for changing the owner of a pet in Fig. 1. Therefore, while Hydra enables simple autonomous interactions (e.g., resource creation or deletion), it cannot express the full semantics of data flows [14].
OWL-S [15] provides a semantically rich framework for describing Web services, including preconditions, ef‐ fects, and complex process models. It supports abstract reasoning about resource modifications, making it theo‐ retically capable of modeling service composition.
RESTdesc [16] extends ideas similar to Hydra using Notation3 (N3) [17], enabling interface contracts through logical implications. Although more expressive than Hydra, RESTdesc similarly lacks a formal model of the data lifecycle; it does not provide mechanisms for tracing how data flows through write-to-read transitions across endpoints.
To our knowledge all semantic web descriptions thus lack direct mechanisms for describing concrete modifi‐ cations to underlying resources (e.g., <database> in Fig. 1). As such, they are not well-suited to applications re‐ quiring fine-grained reasoning about how specific API calls modify underlying resources.
Query-Based Interfaces - Interfaces like SPARQL Protocol [18] and GraphQL [19] expose an underlying dataset as an HTTP-based query endpoint allowing clients to select the specific data they require at run-time. GraphQL will allow you to describe different available resources and manipulations, but similar to syntactic in‐ terface descriptions, the description of the resources is done through natural language leaving room for interpre‐ tation error. The SPARQL protocol on the other hand, is, in the absence of further policies, inherently symmetri‐ cal, meaning the shape of the data one can read matches that which can be written. This limits their use when determinism is needed, or when multiple or underlying resources are required, additionally their interaction method comes at significant costs for the data provider [20]. Our solution enables (and encourages) the semantic definition of multiple resources and additionally allows you to use multiple interaction methods.
In this section we will explain our vision by walking through the pet doctor example (Fig. 1). Within our example definitions we use SPARQL algebra [6] over RDF [21] - due to RDF’s strengths in representing linked, web-native data using IRIs - the broader approach is algebra-agnostic. Any algebra that can express data transformations in a way that preserves semantic meaning and exposes IRIs as first-class citizens could be used (e.g. RML algebra [22] seems particularly useful).
We also emphasize that the description is there to help clients and should only be correct in regard to the be‐ haviour of the described system, it is thus decoupled from the underlying implementation. For example, an RDFbased description may describe a JSON API backed by a relational database. Despite this abstraction, much like a blueprint, the algebraic description is sufficient to generate a server implementation, illustrating the expressive power of the model.
Pet registration - We start by focussing on Bob, the proud owner of two cats. To protect his cats, he requests his agent to register them to the local pet doctor. Since Bob just moved to a new city, the interface of the local pet doctor’s system is not yet known to Bob’s agent. To make Bob’s agent discover the capabilities of the local pet doctor’s system, the agent first request a description of the interface of the local doctor. Within this descrip‐ tion the agent finds how the <post-owners> endpoint manipulates the doctors’ database. The agent discovers the interaction method (e.g. a POST to /owners), the resource representation (e.g. Turtle [23]), and the expected data shape (e.g. a SPARQL ASK [6] query see Fig. 2). The interaction method and resource representation allow for out of band communication, since the agent either supports them or does not - meaning the agent knows their own capabilities. The shape description allows the agent to infer what information it should provide to the endpoint to facilitate a successful interaction. The description also provides the agent with knowledge on the consequences of a successful interaction by providing an algebraic relationship between the endpoint and, among others, the database resource (e.g. using SPARQL Update, see Fig. 3). By utilizing this interface de‐ scription, the agent can 1. infer that it should POST Bob’s data and that of the cats, according to the shape to /owners in Turtle format. 2. verify the consequences are what is expected and that Bob’s cat won’t suddenly ap‐ pear up for sale.
PREFIX ex: <http://example.org/> ASK { ?owner a ex:owner ; ex:name ?ownerName ; ex:pet ?pet ; FILTER(datatype(?ownerName) = xsd:string) . ?pet a ex:pet ; ex:name ?petName ; ex:age ?petAge .
FILTER(datatype(?petName) = xsd:string && datatype(?petAge) = xsd:positiveInteger) . } Fig. 2: ShEx shape of a single owner. <database> contains many owners.
GRAPH <database> { ?ownerBound a ex:owner ;
ex:name ?name ; ex:pet ?petBound . ?petBound a ex:pet ;
ex:name ?petName ; ex:age ?age . } } WHERE { ?resource ex:name ?name ; BIND(UUID() AS ?ownerUuid) . ?resource ex:pet ?pet .
BIND(UUID() AS ?petUuid). ?pet ex:name ?petName ;
ex:age ?age ; BIND(URI(CONCAT(ex:owners, '/', ?ownerUuid))
AS ?ownerBound) .
BIND(URI(CONCAT(?ownerBound, '/', ?petUuid))
AS ?petBound) . } Fig. 3: Declarative description to the agent of how <post-owners> manipulates the <database>.
Requesting pet information - Next in our use case, disaster strikes and one of the cats get sick, to make matters worse our doctor is on holiday. Bob visits another doctor, and now that doctor requires the medical his‐ tory of Bob’s cat stored on the system of our doctor. The other doctor thus tasks their agent to retrieve the files of Bob’s sick cat. Since this agent needs to read data, it would technically be feasible to query all data of our doctor’s system blindly, and filter on what applies to Bobs cat. This approach is currently often taken but comes with sig‐ nificant client and server overhead - our agent is smart and requests the interface description of our doctor’s sys‐ tem. From this description it notices the existence of the database, containing owners and pets. Since the data‐ base resource is not directly exposed, it looks at other, derived resources, finding 1. <get-owners>: list of IRIs of the owner in the system, and 2. <get-owner>: parameterized resources containing the info of owner X and their pets. Each of those resources algebraically describes how they are derived from the database (e.g. using SPARQL CONSTRUCT [6] queries, see Fig. 4 and Fig. 5). When describing parameterized resources, one could use a tenta‐ tive variable in the query that will be bound at a later point. Since the resources are exposed, the description con‐ tains just like before the interaction method and representation. Using the interaction methods you can link the resource parameters to parts of the interaction method, as such using the URI template [10] /owners/{id} we can bind the ‘id’ variable to a variable in the query. Next, we hypothesize that the agent can use the algebraic de‐ scriptions and the input shapes from the manipulation endpoints to compute the shape of the data they can expect when calling the read-endpoints. Using the expected shapes and parameter definitions, the agent will in‐ fer that it can request both Bob’s data and that of his cats when Bob provides his identifier.
CONSTRUCT { [] ex:item ?owner . } WHERE { GRAPH <database> { ?owner a ex:owner .
Pet transfer - Now to end our story in a positive note, Bob decides to buy a third cat. He buys the cat from Alice who is already registered at the same doctor, and asks his agent to register this change of ownership. Once again, the agent requests the description, this time discovering the <change-owners> endpoint. Like before, the endpoint has a required shape description (Fig. 8), a resource representation, an interaction method, and a query that updates the database (Fig. 9). Similar to the parameterized resource before, the update query of <changeowner> contains variables that will be bound at a later stage, the variable in question being ‘id’ and ‘pet-id’ from the URI template /owner/{id}/{pet-id}/change-owner. It is essential to note that the explicit modeling of the <database> plays an essential role in our ability to describe this operation. The change ownership modification shows the definition of a consistency boundary that would not be possible to model using symmetric interfaces.
Need for algebraic descriptions - To conclude we hypothesize that our algebraic descriptions enable agents to: 1. Discover endpoints providing views over given resources, and how to query them, 2. infer how modifi‐ cations can be enacted to those resources, by tracing flows back to the corresponding write endpoints, and 3. how these endpoints can be used through interaction methods and required shapes. In this way, our model enables agents to reason not just about what data resources exist, but how they came to be, how they can be modified, and what such modifications would entail.
We propose a new approach to data interface descriptions by formally linking reads and writes through algebraic flows and explicitly modeling underlying resources. As autonomous agents become more prevalent, machine-un‐ derstandable interface semantics are essential, especially for heterogeneous and asymmetric systems.
By introducing algebraic data flows, we propose a foundation for explicitly modeling read and write opera‐ tions over both exposed and underlying resources. This shift enables agents to reason not only about what data is available, but also how it was derived and how it can be meaningfully modified. This approach builds on skills developers already use to write queries, requiring only a shift in mindset: modeling underlying resources explic‐ itly and exposing interface semantics.
Future work includes formalizing the system with a defined vocabulary and algorithms, exploring policyaware semantics for fine-grained control, and developing privacy-preserving flows where interface descriptions can be selectively disclosed. The authors next step will be to tackle the first point and create a proof-of-concept implementation.
Jitse De Smet is a predoctoral fellow of the Research Foundation – Flanders (FWO) (1SB8525N). The described re‐ search activities were supported by SolidLab Vlaanderen (Flemish Government, EWI and RRF project VV023/10) Ruben Taelman is a postdoctoral fellow of the Research Foundation – Flanders (FWO) (1202124N). PREFIX ex: <http://example.org/> ASK { ?owner ex:new-owner ?someIri .
FILTER( isIri(?someIri) ) .
During the preparation of this work, the author(s) used Chat-GPT-4 in order to: Paraphrase and reword, improve writing style, perform grammar and spelling checks, and critically review the text written by the authors to high‐ light essential information. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s)full responsibility for the publication’s content. [5] Azzam, A., Taelman, R., Polleres, A.: Towards Cost-Model-Based Query Execution over Hybrid Linked Data Fragments Interfaces. In: Harth, A., Presutti, V., Troncy, R., Acosta, M., Polleres, A., Fernández, J.D., Parreira, J.X., Hartig, O., Hose, K., and Cochez, M. (eds.) The Semantic Web: ESWC 2020 Satellite Events - ESWC 2020 Satellite Events, Heraklion, Crete, Greece, May 31 - June 4, 2020, Revised Selected Papers. pp. 9–12. Springer (2020). doi:10.1007/978-3-030-62327-2_2 [6] Harris, S., Seaborne, A., Prud’hommeaux, E.: SPARQL 1.1 Query Language. W3C, https:// www.w3.org/TR/2013/REC-sparql11-query-20130321/ (2013). [7] Baker, T., Prud’hommeaux, E.: Shape Expressions (ShEx) 2.1 Primer. https://shex.io/shex-primer-20191009/ (2019). [8] Hadley, M.: Web Application Description Language. W3C, https://www.w3.org/submissions/wadl/ (2009). [9] OpenAPI Specification. https://swagger.io/specification/ [10] Gregorio, J., Fielding, R.T., Hadley, M., Nottingham, M., Orchard, D.: URI Template. RFC. 6570, 1–34 (2012).
doi:10.17487/RFC6570 [11] AsyncAPI. https://www.asyncapi.com/en [12] MCP: Model Context Protocol. https://modelcontextprotocol.io/ [13] Lanthaler, M., Guetl, C.: Hydra: A Vocabulary for Hypermedia-Driven Web APIs. Proceedings of the
WWW2013 Workshop on Linked Data on the Web, Rio de Janeiro, Brazil, 14 May, 2013. 996, (2013). [14] Taelman, R., Verborgh, R.: Declaratively Describing Responses of Hypermedia-Driven Web APIs. In: Corcho, Óscar, Janowicz, K., Rizzo, G., Tiddi, I., and Garijo, D. (eds.) Proceedings of the Knowledge Capture Conference, K-CAP 2017, Austin, TX, USA, December 4-6, 2017. pp. 34:1–34:4. ACM (2017). doi:10.1145/3148011.3154467 [15] Martin, D., Burstein, M., Hobbs, J., Lassila, O., McDermott, D., McIlraith, S., Narayanan, S., Paolucci, M., Parsia, B., Payne, T., others: OWL-S: Semantic markup for web services. W3C member submission. 22, (2004). [16] Verborgh, R., Steiner, T., Deursen, D.V., Coppens, S., Vallés, J.G., de Walle, R.V.: Functional descriptions as the bridge between hypermedia APIs and the Semantic Web. In: Alarcón, R., Pautasso, C., and Wilde, E. (eds.) Third International Workshop on RESTful Design, WS-REST ’12, Lyon, France, April 16, 2012. pp. 33–40.
ACM (2012). doi:10.1145/2307819.2307828 [17] Berners-Lee, T., Connolly, D.: Notation3 (N3): A readable RDF syntax. https:// www.w3.org/TeamSubmission/n3/ [18] Feigenbaum, L., Todd Williams, G., Grant Clark, K., Torres, E.: SPARQL 1.1 Protocol. W3C, https:// www.w3.org/TR/2013/REC-sparql11-protocol-20130321/ (2013). [19] GraphQL. https://graphql.org/ [20] Buil-Aranda, C., Hogan, A., Umbrich, J., Vandenbussche, P.-Y.: SPARQL Web-Querying Infrastructure: Ready for Action? In: Alani, H., Kagal, L., Fokoue, A., Groth, P., Biemann, C., Parreira, J.X., Aroyo, L., Noy, N.F., Welty, C., and Janowicz, K. (eds.) The Semantic Web - ISWC 2013 - 12th International Semantic Web Conference, Sydney, NSW, Australia, October 21-25, 2013, Proceedings, Part II. pp. 277–293. Springer (2013). doi:10.1007/978-3-642-41338-4_18 [21] Cyganiak, R., Wood, D., Lanthaler, M.: RDF 1.1: Concepts and Abstract Syntax. W3C, https:// www.w3.org/TR/2014/REC-rdf11-concepts-20140225/ (2014). [22] Oo, S.M., Hartig, O.: An Algebraic Foundation for Knowledge Graph Construction (Extended Version).
CoRR. abs/2503.10385, (2025). doi:10.48550/ARXIV.2503.10385 [23] Carothers, G., Prud’hommeaux, E.: RDF 1.1 Turtle. W3C (2014).