Added docs page on Scenes and Perspective

_docs/05-action-server.md

@@ -12,7 +12,23 @@ An Action Server is a resource which exposes views to make actions on a World Se
 
 # Discovery
 
-TODO: currently in development. During Action Discovery, the client will discover the ways in which it can interact with a given graph via the providing Action Server. For example, I might give it a location, and it might return a Transit Activity endpoint for me to use.
+During Action Discovery, the client will discover the ways in which it can interact with a given graph via the providing Action Server. For example, I might give it a location, and it might return a Transit Activity endpoint for me to use.
+
+Just like in [Content Discovery]({{ 'docs/04-content-server' | relative_url }}), the client MUST generate a Scene, and then they will send this in a POST request to the `mudlogic:ActionDiscoveryEndpoint` returned by the server during the [Server Discovery]({{ 'docs/02-server-discovery' | relative_url }}) phase.
+
+Upon the reception of the Scene, the Action Server SHOULD parse it for objects, to understand the actions that it can offer. The endpoint MUST return a graph of available actions to the client in at least Turtle format, and it SHOULD serialize each action for the client's use. It MUST serialize the type of the action, and the `mudlogic:actAt` property e.g.
+
+```
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix mudlogic: <https://raw.githubusercontent.com/Multi-User-Domain/vocab/main/mudlogic.ttl#> .
+
+<https://raw.githubusercontent.com/Multi-User-Domain/vocab/main/mudlogic.ttl#Transit>
+        a       <https://raw.githubusercontent.com/Multi-User-Domain/vocab/main/mudlogic.ttl#Task> ;
+        rdfs:label "Transit Task"@en ;
+        mudlogic:actAt <http://localhost:8080/mud/act/task/> .
+```
+
+TODO: the client must currently implicitly support the action to be able to POST to this endpoint. Using Shapes, we would be able to return the input requirements of the endpoint, and the client will be able to do this on-the-fly, even without having seen this action before! (see [Git issue](https://github.com/Multi-User-Domain/mud-jena/issues/44)).
 
 # Acting
 

_docs/07-scene.md

@@ -0,0 +1,35 @@
+---
+
+layout: doc
+title: Scene and Perspective
+lang: en
+lang-ref: scene
+---
+
+{% include early-dev-disclaimer.md %}
+
+A Scene refers to a graph containing models pertaining to resources within a user's perspective, for example the characters, buildings and context of the café in which a player happens to be sat.
+
+Both Action and Content server provide features using scenes - the Content Server might describe it and the Action Server might analyse it to find available actions.
+
+# Implementation
+
+## Scene Generation
+
+A simple client can POST a scene description by dumping the characters and objects which it knows to be present - and this is valid - but the client MAY also seek to "develop" the scene beforehand, for example by making a call to a Scene Generation endpoint which integrates.
+
+At the time that the client passes a scene to the scene description utility, it SHOULD be considered final and the Content Server SHOULD NOT generate any new objects into the scene, which for example frees the client to asynchronously call many Content Servers with the finished scene.
+
+If the server supports scene generation, then it SHOULD return a `mud:sceneGenerationEndpoint` property in its [MUD Configuration]({{ 'docs/02-server-discovery' | relative_url }}), with a URL value where the endpoint can be found. The endpoint, if supported, MUST receive a POST request, with the data containing an RDF graph of resources to be included in the scene. The endpoint should inspect this graph, insert any generated content and return the completed graph with a status code `200`.
+
+## Scene Contents
+
+The contents of the Scene SHOULD include the objects which were passed by the client in the request, and any physical world objects which have been injected, for example a generated character whom the player could talk to.
+
+TODO: The Scene MAY also include contextual, non-physical objects including social context and abstract information.
+
+# Notes
+
+The server MAY incur side-effects to World state during the scene generation if it chooses - for example triggering an event.
+
+A client MAY or MAY NOT confirm the perspective and show it to the player. The act of calling the Scene generation endpoint SHOULD NOT be considered in the server to meaning that the player is committed to the scene.