Exchange formats and APIs

• Questions– how and when to access metadata?– lifecycle/status – how to access? can things disappear?– is CSV enough?– is Atom enough?

• Need to know use cases for exchange– update of register by maintainer– access to latest version – mirror/federate e.g. for performance or discovery

Update

• Up to the registry service and its own workflow– INSPIRE – CSV ingest– EEA – offline batch processing, source scraping– UK – RDF via REST API, separate CSV to RDF service– ...

Access

• focus on content not metadata• variety of formats– RDF– CSV– JSON(LD)– ISO 19135-2 XML– ...

• support RDF– but with what vocabularies?– not just SKOS

Federation/mirroring

• Need full metadata• May or may not need version history– current, tagged snapshots, whole history

• API should support different views?• Formats– Atom enables discovery of what’s changed– ISO19135-2 XML encoding when doing full metadata

exchange including management information– can also support RDF formats– CSV not so suitable here

APIs

• access– with metadata– register only or with content– paging control for large lists– version - history, version at time, tagged version

• validation• search

– text and structured properties (facets)• workflow & user management

– out of scope• proposal and reservation

Propose/reserve

• could submit empty entry to registry?• API to propose entry?

• separate proposal service– preview– discuss and refine– only submit to registry when agreed– though can still be rejected by Register Manager

API Conclusions

• agree REST API• some clarification of use cases and requirements– separation of proposals and discussions, workflow

• detailed API would require real design effort– precise list of operations

• URL templates

– precise data model and formats in the exchange– status flags