...
- reconciliation through open refine - need to filter by date range
Common External Search Format/Ontology
Requirement: Allow access to vocabulary data via a consistent format, regardless of how the data is managed internally.
Benefits:
- Clear semantics for the fields (e.g. name, birth_date, occupation, etc.) in the format, to be documented only once, rather than by every publisher separately
- Fields provide a common set of data elements to be searched using advanced/fielded search
- Entries from different systems can be easily managed together in a single data management platform, such as a cache or aggregator, without having to re-process the data.
- Rendering and processing code need only be written once and applied to all publishers that provide the common format
- Publishers do not have to change anything they are doing currently to provide another format, only expose an API which transforms their internal data structures into the common format. This can also be done via a third party "shim" that acts as a gateway between the consuming application and the target vocabulary data. (i.e. map from internal representation to external common representation)
E. Lynette Rayle How to interpret `consistent format`?
Interpretation 1: Format is the encoding language used to express the data (e.g. json, json-ld, rdf-xml, atom, or something else, pick one)
Interpretation 2: Format is the structure of the data (e.g. a person's preferred name can be encoded in a field labeled `preferredName`, `skos:prefLabel`, or something else, pick one)
Interpretation 3: Both the above
Rob Sanderson Both, somewhat orthogonally. Once the data is structured correctly, it's easy to translate between media types.
The data structure (2) somewhat determines the possibilities for the media type (1).
E.g. skos, in json-ld would be one set of structure + media type.