Web ontologies and research paradigmatics

File under: 1.6 What are P2P Politics? — Commons Transition Primer, Money of the Commons — P2P Foundation

Namely, the fact that Promises, Apologies, Guesses and Memories are not well understood and are under theorized psycho-geometries. Though Action exists, the reasons constitutive of the ground of their warrant are under described in the ontologies of web semantics. Accessibility roles exist to delineate the navigational priorities of clients, though the creation of generic clients is increasingly rare in the wild as links generally prioritized session-based state management or tree (graph), trie, tuple, etc. structures, or hierarchical structures, but rarely Bloom filter or CALM semantics, though sometimes temporal semantics a la Leslie Lamport, the W3C, etc. So naturally Promises, appear in UI language, via JavaScript and something like Websockets, where soundiness is truthiness is chattiness is some state machine non-axiomatized in rules of interference but nevertheless insufficient for surreal, non-relative prefigurative affordances. Whatever protocol you’re issuing, it’ll likely be all, allSettled, any, etc. that they’re resolved in the interface. Apologies, Guesses and Memories are not part to the JavaScript language’s interest nor its developers, but should it be to web developers? Should web developers abandon the presumptions and assumptive logics of systems developed against the alleged CAP theorem, while preserving PRPL, RAIL, POUR, etc., but with a re-imagining of value of the computation? Memories nor Guesses, yet one would expect Apologies if Promises were present, the latter of which is expressed where the others are expressed neither in the userland (JavaScript, W3C, etc.) nor CAP theorem literature. Yet they appear only under one paradigm of research: development, functionalism, etc. We’ve seen logical and temporal clocks suggest the idea, but usually through some auto-coordination of callbacks through front end measures (fetch, $.ajax, etc. coupled to a Promise().next|all|any|etc (W3C) and Generator().next, Monad().lift (Crockford), etc.). The material mechanics of contracts are supposed to be digitally underwritten by these semantics; more than anything should we expect to find Memory or even Guess as part of some API in the wild, but generally vector clocks are situationally contextualizing objects as we go when we use systems like Riak. All the same, APIs are mostly driven by Promise and some HTTP interface in which developers do anything from practice POST as a service (anti-pattern) or some mixture of session-based CRUD access, and more rarely access token-centric sessionlessness as expected by REST (PASETO, JWT, etc.).

What goes inside a promise other than a timeout, as the common cursory example shows? Again, we’re thinking:

HTTP VERBS -> Bag-O-Promises -> (con’t.)…  /__ Proposals (TLA+ (SAM), blockchains, etc.)
/____ Memory (Functionalists)
\____ Apology (material semiotic)
\__ Guesses (minimalistic K=TB)

So does REST have any allegiance to the HTTP verbs or any of that: whether you’re using HTTP or sockets, it doesn’t really matter; you have to use Promises as the underlying implementation? The goal is a virtual state machine, a distributed hypermedia application: PNGs embedded with DOM interfaces that support all platforms running headless engines; MP3s with Winamp players embedded in their headers that store internet jukeboxes or maybe they contain their own torrent client as a wallet that pays for itself. Is it malware? Is it content? Is it administering itself? If it’s all Promises and POSTs, what’s left? Why should we expect a WarrantyPromise to be realized in the mechanics of conveyor-tube of Promises?

https://www.semanticarts.com/gist/ in Protege

Are we actually writing about the world, less the real, or even accelerating it, in virtue of this semantics that fails to reflect the rich semiotics of its realness? SAM introduces Proposals: are these not but another “voter” model-theoretic system pushed through a conveyor tube wherein time in temporalized with an assumptive logic of parallelism? Has parallelism even truly been achieved, or are we imagining a bunch of async link relation calls without representational access in the protocol is a true test of REST? What’s in a link relation? Naturally, Promises will be used, most probably to implement any of them at the presentation layer (think OSI), and there will be presumptions about session, and transport, the application’s evolvability, etc. We’ll be convinced it’s a series of agreements and proposals to change state, and subsequently some states follow which to not contradict the entire edifice of prior create or update commands. We want consistency, or sometimes availability or partitions we can afford: how these decisions are played out in SLAs, etc. and presumably it’s a trade off or coalition formation yahoo or something. Does REST care? Probably, who knows. It’s an architectural style for organizing promises, fundamentally, and the web is fundamentally a distributed hypermedia application.

Web ontology is the study of discrete entities and value objects related to intercommunication and data exchange activity by humans on a planet. No human has successfully implemented distinct and clear REST in a microservices intercommunications of post-civilizational scarcity. Alice and Bob need to get stuff from L1 to L2 somehow after whatever ceremony they undertake individually or jointly through probabilistic knowledge reinforced by digital, cryptographic protocological forcing and generative identity formation. Bear to mind: REST is also informed by ARIA, which presumably would have an affordance model representation with non-trivial cases such that they include necessary HTTP interfaces (see Using the aria-describedby attribute and Protocol for Web Description Resources (POWDER). How do we afford protocol access to the front end without much ado about JavaScript (writing as little with Promises with greatest value maintainably, evolvably, interoperable, cross-platform compatibly, etc.)?

Promises structure digital property relations

Some languaging capabilities are afforded through the use of Promises as the underlying mechanism of RESTful architectures. In the web space Types of certain kinds have emerged and at various layers in the axiological practice of state management. There are “actions” in the web sense and sometimes RESTful objects may manifest them. Proposals generally are used in simple state machine programs to enable these actions, elsewhere application provide an API via a server through an HTTP interface whereof all kinds of locking with VectorClock or they’re document stores or relational stores, you name it.

const firstThereWasA = Promise.resolve({ _links: { ... } });

And we spin about some opinionated HTTP abstractions and programs to issue requests which virtually command systems or imply commands will be executed:

Command Query {Response} {Reject}
(Develop) (Describe*) (Interpret) (Explain)
[Proposal] [Memory] [Guess] [Apology]

RESTful link relations enabled:

        prev           *describedby
... aria roles implying navigational capabilities ...
... schema.org actions ...
... intentions, categories, etc. (gist core) ...

Every request status should minimally return some options, really even if the resource itself has no meaningful or purposeful actions to enable: guesses, apologies and memories can constitute other kinds of meta-relational (think meta-knowledge schemas) links to the resource for which navigational capability in generic clients is obliged. They’re not all promises perhaps and proposals are a unique form that involves creation while memories, etc. go further to structure proposals themselves; and so a promise to promise exists just as a memory to propose, without presupposing the proposal’s status as a proposal in the causal context outside of a given memory. Actions, in general, are not active merely in virtue of being proposed, but the system a a conveyor tube tacks them on in a transaction history: we are here talking of guesses, memories, etc. as constitutive of the system-theoretic heuristic in the first place; the system is apologizing; the system is guessing, as code we can actually see, as distinct from /promising/ or always merely promising requests to be recorded as transactions. Sometimes the system in question is guessing, as we said in the code, or apologizing or memorizing and remembering (beyond just storing JSON documents in LocalStorage but in fact memorizing itself is a program, not merely an existence check on data; here we might recall staleness, valid time vs transaction time vs decision time, etc.). Guesses certainly are generated and proposed, but also merely generated and thrown away. We can propose to throw away a guess after we propose its outcome (maybe as a source of randomness, as I threw some dice). My guess can also not be a proposal toward anyway and can exist in other ways in relation to memories and apologies. Are transactions necessary to bind these relations?

But may I (not) be making a transaction in virtue of guessing anything or apologizing or memorizing? We may grant transactional analysis, but must the act of guessing itself imply a promise or that a structure of a promise is implicated? Is guessing fundamentally promising? We can certainly say someone promises to guess, but is the act of guessing itself a form of promising?

ODRL applies Rules on (Potential) Actions (Promises), etc., etc. And out of that:

HTTP Status Codes

How we treat status codes in relation to link relations themselves is another story for another time.

Are Apologies, Guesses and Memories on par with Promises, rather than defined in terms of them? Doxastically are they all indexical, representational, etc. in just the same way? Can we epistemically engage in them jointly? How do computers share understanding as to these individual concepts? Is an apology not something completely other than a promise, which is pronounced regardless of its transactional determinant’s resolution?

We can promise to guess but never guess to promise, at least not but in that we are promising already; but if we are promising to guess, there is no background guess to which we are already committed. In each control abstraction object, we have an expected grammar that roughly aligns to a series a prompts we must undertake regarding the fact of consciousness and its structure. Are promises guesses because joy is pleasure, or because fear implies a belief? Are promises and guesses irreducible and not explicable in terms of one another, bearing in mind that proposals also imply a promise of some sort, at least bearing a probabilistic content on the outcome of the likelihood of what is proposed.

const e = EventObjectWithAStateChanged;
const memory = new Memory((access, reject) => access(e));
const guess = new Guess((announce, reject) => announce(e));
const apology = new Apology((pronounce, reject) => pronounce(e));
const promise = new Promise((accept, reject) => accept(e));

Could these be schema.org Actions? Arguably. Is designating so the right layer (at the HTTP request as opposed to part of the source code) or context for abstraction, without leaks, in order to contextualize testably, conservatively, fruitfully, etc. completive, deductive, emergentive and conclusive information? Or must it be in the JavaScript composition itself? Surely we could draft a Guess as a Promise, could one not access one’s own guess? This seems certainly possible — but would it be a Promise to access in order to determine said alleged access? At once we see an infinite series of Promise chains that would enable operator operosity over such quantificational domains. Such is minimally necessary even for lambda compositions. Have we encountered the Laruellean data type? — The Memory, the Guess, the Apology? Is a Memory just a Promise? When I memorize, am I promising? When we recall a memory, is it through a Promise? The latter is easily rendered in Mongoose/Mongo. But why should it be a model and not in the functionalization of the application itself? When I access a memory, am I inspecting a promise to myself? There may certainly be a transactional history of its existence, but is this history also the decisional, formal and value history? A memory may be undecided or failing formal or valuational structures, and yet we may have record of a transaction. What sense of time do we adopt as we talk about such would-be models? How do the data types relate to temporal relations as heuristic methods for cultivating metrics of virtual forcing, not merely yet another representationalist, instrumentalist, cognitivist theory of computation to be foreclosed to the real?

Is memory an action? Well, maybe not for humans, in the sense that one is enacting one’s vocal acts within the boundary of the dream’s implicative opacity, to which our descriptions will be confounded if we use universal verifiers like UUIDs as we query back into these relations. Just what are we memorizing anyway that wouldn’t be distinguished as a promise that we must recognize? We do not lose recognition capability in this idea, but rather the way we implement eventual consistency changes: our domain model is itself capable of promises, not merely recording that an agent promised in transaction X, or also guess, etc.; but can the domain modal itself guess? Yes, in a sense: it can read a transaction to execute a guess via CRUD API. But I want the model to guess in virtue not of a transaction based on a promise, since we’ve previously described how it can fundamentally be detached from a promise (I can promise to guess, but I cannot guess to promise, in the absolute sense; though I can promise to promise). It comes down to asymmetry: guessing to promise versus promising to guess; in the former nothing is create in the promise by way of the guess that conditions it or rather lack thereof of conditioning; the internal nature of the guess does not prevent the promise from being activated. For the promise, something of its nature conditions the quality of the guess: a false promise to guess will yield the likely outcome that a guess is never rendered. A false guess to promise may yield a promise is rendered. So a guess to promise has a simple nature, even if a promise is instantiated: the guess does not stipulate the interpretation of the promise; but for a promise to guess, one may have to hold out if the promise was conceived without compromising circumstance. Even if I could guess to guess I am not committed to anything by this structural relation: a promise commits me to a promise that is structurally related, in itself, to another promise; a guess is not structurally related to another guess except in a transactional sense. Do its contents in some sense depend on its predecessor? What if they are simultaneously produced in the temporalization process and we must record their side-effects according to valid time, not mere transaction time? When does temporality become: at the stage where we could be drafting of promises, or at the stage at which a request has virtue of promises resolving (e.g. as schema.org Actions)?

We fundamentally separate link relations and actions: Practical Hypermedia Controls, as they are merely two branches in the JSON response (application/json). Yet we can declare any MIME-type we wish. Is it transactional? Invariably will we attempt to achieve some form of consistency, but which attributes, immutability, safety, etc. pertain to perdurant, versus otherwise temporal objects? Objectivationally the UI component, button, input, etc. whatever it is, can accommodate a list of actions, yet its affordance is not the act itself. The affordance may be immutable, idempotent, etc. such that it is not a Promise in any sense but one functionally developed in the interface: it is not an interpretation, or an explanation or description, but a development. That my transaction fired off is no guarantee that I will uphold it; a `Memory` captures this idea when we are doing disorderly programming. The main idea here is that we are introducing declarative disorderly programming to REST architectural style as a philosophy of hypertext (when we put hypertext in hypermedia itself and turn probabilistic contents into internet jukeboxes, ATMs, etc.).



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store