Candidate high level technical approach

From Spatial Data on the Web Working Group
Jump to: navigation, search

This approach summarises what I (Bill) think is emerging from our discussions and the example implementations. For discussion.

1. Metadata in RDF, real data (range) in a more compact format [JSON array in UoR approach, base64 encoded image in ANU prototype so far]

2. RDF metadata can be expressed as JSON-LD with a specified @context so making it easy to read - and possible to ignore namespaces etc if you want to

3. Metadata for an extract in one document with an identifier, linking to one or more ranges as separate resources? So you can retrieve the extract metadata quickly and decide if it's what you want, without having to retrieve potentially large payloads.

4. Metadata should include a specification of the domain, provenance, info on what is being measured and how - including where necessary enough info to transform values in the range to physical quantities?

5. While different extracts will need different domain specifications, many extracts might share provenance and discovery metadata. Should we separate those out into a higher level shared/referenceable doc?

6. Special treatment for gridded domains? common, compact for large amounts of data.

7. How to deal with time dimension in a gridded domain? Even if space is on regular grid, available time intervals may not be regular (CoverageJSON seems to have an approach to that, either listing values or specifying start/stop/number).

8. Support point cloud domains? The range could be expressed in the same way as for gridded domains - essentially a 1D array, but the domain could be a list of (x,y,z,t) coords. This is pretty general so could cover more or less arbitrary cases, with the gridded approach being an efficiency/shortcut for cases where it can apply

CoverageJSON examples

ANU examples