Discussion: Making feeds valid JSON-LD

[ldodds]

The Modelling Opportunity Data Specification encourages use of JSON-LD. We recommend that publishers using RPDE to publish opportunity data ensure that their data elements contain valid JSON-LD documents including a @context.

If the RPDE format was also valid JSON-LD then we could define a single context to cover both specifications. This would slightly reduce payload size and would make the specifications more consistent.

Syntactically, to make a RPDE feed into a JSON-LD document, all that's needed is a @context which declares a @vocab.

But there are some issues to consider:

• The data element is currently defined as being able to transport any custom JSON data model. This means a single JSON-LD context can't define mappings for the properties of all possible feed entries. One solution would be to require a publisher who is using their own custom data element to ensure it is valid JSON-LD and define their own context to declare their properties. Another would be to deprecate use of custom data elements but this would be a larger breaking change

• Should the structure of the feeds use an existing vocabulary, e.g. Hydra collections. Some changes to feed structure, e.g. addition of view would be required if we decided to use that specification. (View separates out the paging from the Collection being iterated over)

• Where additional types and properties should be defined to clarify semantics of the feed. E.g. an item might be viewed as a "Record" with its data being the record contents. This is consistent with the existing specification

• We'd need to ensure guidance relating to custom context and properties for use in the Modelling Opportunity Data specification is also generalised for use in RPDE.

The first change is likely to have the most impact on existing implementations. While only a few feeds are using non-standard data elements, the intention was for RPDE to remain independent to the Modelling Opportunity Data specification. This would bring them closer together. We'd need to decide whether that's useful or not.

While there are other details to consider, its probably best to defer discussion on these changes for a later version of the specification.