summary notes

The data API allows meta-data and data to be requested and delivered from datasets. It is a development of the data cube API from earlier projects. The datasets don't have to be cubes but cubish. Terminology needed for the elements of the dataset -- Components? (clumsy & generic, want something better: atom unit piece part face facet, picked Aspect). Includes GEO types (we don't know which yet but bounding box plausible candidate) and dates.

Components named by prefix:localname for given set of prefixes (no Elda-style shortnames). Component descriptions include label/description/role/range{type,bounds}. May be part of hierarchy, includes level.

API queries/results are initially JSON. (May allow alternative results formats eg CSV.) Note API is for programs not people. Data queries are POSTS. Rationalise existing ideas to make more uniform query/encoding.

API allows search of dataset by constraints on values; includes oneof[v1; v2 ...], le/lt/ge/gt value, below [v1; ...] for hierarchies. Values are JSON values plus encodings to allow dates/langtags/resources/sets.

Configurable from DSD + hints (eg ranges lo..hi [which aren't in a DSD]) or direct spec. In any case model has results which are records with attributes. Attributes may be property paths, ie the record can be a condensation of RDF data. (This is an analogue to Elda views.)

Paging is available but the normal use is to get all the data implied by a filter query.

Queries arrive and are converted to SPARQL by (configurable) SPARQL processor code. One single translator not likely to be sufficient, experiences suggests that performance may require translations tuned to particular query types.

API to follow.