Getting information into PROMS Server

Last modified by Car, Nicholas (L&W, Dutton Park) on Aug 19, 2016

Types of provenance

Three types of provenance and related information can be sent to PROMS:

  1. Reports
  2. ReportingSystem definitions
  3. Pingbacks

Reports are the main thing that PROMS Server is set up to receive. ReportingSystem definitions are descriptions of the systems that send Reports. A ReportingSystem must be pre-defined within a PROMS Server instnace in order for it to allow the receipt of a Report.

Pingbacks are essentially Reports of provenance generated by 3rd parties that send them to data owners in order to inform those owners of how they have used the owners' data. PROMS Server can both generate Pingbacks for others and receive them. 

Sending information to PROMS Server

The only one way to get any kind of information into PROMS Server is to send it via an HTTP 1.1 POST to a relevant RESTful endpoint.

Reports are sent to {PROMS Server URI}/id/report/

ReportingSystem definitions are sent to {PROMS Server URI}/id/reportingsystem/

Pigbacks are sent to {PROMS Server URI}/id/pingback/

Information processing


Once a provenance Report has been sent to PROMS Server, the following occurs:

  • Validation: the provenance is validated according to a series of RuleSets
  • PID Replacement: if valid, certain sorts of provenance data is processed to assign it persistent URIs
  • Stored: it is stored in PROMS Server's RDF triplestore

PROMS v3.1 introduces the following additional steps for incoming Reports:

  • Pingback sending: after storage, PROMS Server will attempt provenance pingbacks 
    • different approaches are selected based on the settings of the particular PROMS Server

PROMS v3.2 introduces the following additional steps for incoming Reports:

  • Signing: before storage, PROMS Server will seek a reporting system's digital signature and countersign the incoming provenance
    • whether this "Secure Prov" feature is use is set by the server instance implementers

Validation by RuleSets

All Reports coming in to PROMS Server instances must pass validation at a number of RuleSets which are executable code modules that check constraints. They are currently implemented in Python but could be implemented in any language. See the RuleSets page for comprehensive RuleSet information.

Each RuleSet must be passed before the next is tested. All RuleSets implemented in an instance must be passed in order for provenance to be stored. PROMS Server implementers may make additional RuleSets on top of the basic ones provided by PROM Server out-of-the-box.

PROMS Server v3.x implements the following RuleSets:

Basic RuleSets

Fig. 1: Basic RuleSets in PROMS Server v3.x.

PROV-O RuleSet

The PROV-O RuleSet is the most fundamental PROMS Server RuleSet. It ensures that provenance sent to PROMS Server is valid according to the PROV Ontology which is the main standard used for provenance by PROMS.

This RuleSet is an implementation of PROV Constraints and is based on Paul Groth's Prov Check code.


The PROMS-O RuleSet is another fundamental PROMS Server RuleSet. It ensures that provenance sent to PROMS Server is valid according to the PROMS Ontology which is a profile of the PROV Ontology.

Additional (User Defined) RuleSets

Implementers of PROMS Servers may add any number of their own RuleSets on top of the PROV-O and PROMS-O RuleSets. This should be done if implementers wish to further constrain the provenance coming in to their instance of PROMS Server. The reason for this may be something like the desire for all provenance reported to their instance to have further properties in addition to those specified by PROV-O & PROMS-O. Perhaps implementers need to have a cost code associated with each provenance record or perhaps they wish to constrain the PROMS data model further by insisting that every Report contains an Activity that uses both data and code.

Existing User Defined RuleSets are:



Pingback sending


Secure Prov



    Add new comment