Standardize a Policy (or Argument, or Certificate + Certifier)
Use case
Currently, the Publisher of a docmap may have its peer review policy attached to it. however, the peer review policy for an object represented in a docmap may not be that of the docmap's publisher. Since we are so loose about what kinds of entities may publish Actions or artifacts, we should be able to more granularly link a specific assertion in a step to the policy that argues for it.
Long term, these could be composed into reasoning about the Docmaps themselves, if there were a reason for that.
Proposed solution
This raises a few interesting questions:
The assertion is a stepwise property, not an Action property. Steps are ephemeral to docmaps. For that reason, it may not be the case that the assertion exists outside the docmap itself, but the Policy does. Therefore a Docmap publisher should be able to claim that an extant Policy applies to the validity claims of an Assertion without that connection having been made by the owner of the Policy. These claims should be verifiable by computation when correctly structured.
That means that Policies would ideally be representable as a Docmapsy entity, and linked RDF-wise to the Assertion, and some standard procedure for determining whether the contents of the Step actually do meet the criteria of the Policy should exist. This might mean, a Policy is a function (Step) -> [status] array, and is signed by some entity. This MAY expose the whole system to some degree of code injection, it bears further design thought.
Since the Policy may realistically rely on a relation between the Inputs and the Actions, not just the actions alone, we finally have some notion of a computational reason for Inputs to be more than trivially specified. However we don't want the inputs to have to carry over responsibilities of the preceding Steps (such as the Assertions). Can we be sure that a policy doesn't depend on reading prior Assertions? We should think of some examples that help us understand this.
Peer reviewer identities will often need to be anonymous but verifiable. This may mean that the Policy, if specific to an Organization for example, would include direct reference to cryptographic identity information. This is possibly undesired, in which case Policy semantics would have to be generic and pluggable with separate Identity trust lists and so forth.
Protocol semantics improvement
Description
Standardize a Policy (or Argument, or Certificate + Certifier)
Use case
Currently, the Publisher of a docmap may have its peer review policy attached to it. however, the peer review policy for an object represented in a docmap may not be that of the docmap's publisher. Since we are so loose about what kinds of entities may publish Actions or artifacts, we should be able to more granularly link a specific assertion in a step to the policy that argues for it.
Long term, these could be composed into reasoning about the Docmaps themselves, if there were a reason for that.
Proposed solution
This raises a few interesting questions:
assertionis astepwise property, not an Action property. Steps are ephemeral to docmaps. For that reason, it may not be the case that the assertion exists outside the docmap itself, but the Policy does. Therefore a Docmap publisher should be able to claim that an extant Policy applies to the validity claims of an Assertion without that connection having been made by the owner of the Policy. These claims should be verifiable by computation when correctly structured.Additional information
See #51 and RDF-Star