This is an architectural overview of a finite state machine for semantic web agents

Introduction

The motivation is a lack of any coherence in how a semantic web agent (with more sophistication than just a scutter) might go about consuming, processing, and acting upon RDF content retrieved from a "semantic web" in a semi-deterministic way. Much of this is motivated by Jim Hendler's must-read article Where are the Agents? and a follow-up "answer": Where are the Semantic Agents?.

Furthermore, I feel that with all the inference capabilities FuXi is now equipped with, if there are no 'killer apps' that can immediately become cannon fodder, then there must be something naive (and perhaps vacuous) about the notion of a web of data with infinite value to autonomous agents. At the very least, some consensus on an agent protocol that addresses the mechanisms that Web Architecture alone is not able facilitate is needed. Agentem is an experimental python-dlp module to investigate what such a protocol should look like. Much of this design sketch is motivated by the ESW wiki: A "Humane" Policy for Intelligent Web Agents and Interpretation via RDF/OWL, Tabulator: Exploring and Analyzing linked data on the Semantic Web , and an older article on a scutter protocol for Redfoot (one of the "original" semantic web agent frameworks): A RESTful Scutter Protocol for Redfoot Kernel

Parameters

The finite state machine documented below is meant to be a parameterized process flow with the following variables

• A list of RDF predicates which are considered "Graph Links"
• An indication of which of these predicates require a mandatory dereference of the target IRI
• An integer representing the maximum recursion depth for traversing (optional) graph links

FSM Diagram

Notes

The process states marked with an asterix are further discussed below (going in top-down order):

Default, Provenance Graph for REST Metadata

This FSM is meant to drive a single RDF dataset. In particular, the default graph is used for persisting HTTP request headers for use in constructing RESTful, subsequent requests for RDF graphs. This allows strong-caching such that the same graph (linked from distinct directions) will only be parsed once if the server supports HTTP headers such as If-Modified-By, and Etags, etc... See A RESTful Scutter Protocol for Redfoot Kernel for more on this mechanism. Currently, "HTTP Vocabulary in RDF" seems like the most promising vocabulary to use in this regard.

"Lazy" Content Negotiation

In addition to storing HTTP response headers, the protocol also requires that an indication of the set of Accept headers that resulted in a successful dereference of an RDF graph serialization be stored in the provenance graph and used to determine whether or not to attempt subsequent content negotiated requests.

Parameterized graph traversal

As mentioned in at the top of this document, a set of predetermined RDF predicates should serve as input to the graph traversal "loop."

A Graph Naming Convention

Upon successful parsing of the Graph IRI, the agent should update / create (depending on the result of the "guided" request) a named graph in the data set with an IRI which corresponds to the racine of the full source IRI.