Broker design reference

[krzysztof]

Outline

1. REST API
2. Queries
   1. Version Roll-up
   2. Grouping IDs
   3. Filtering results (Post filter)
   4. Notifications (generation from query?)
3. Architecture
   1. DB models
   2. ES mapping
   3. Redis?
4. Notifications
5. Test data
   1. Open citations
   2. DLI
   3. ADS data
   4. Generated
6. Metadata
   1. Object metadata (title, creator)
   2. Publisher/provider/Link publication date (relationship metadata)
   3. Metadata conflict resolution (conflicting titles, creator lists)
7. Ingestion
   1. Update grouping
   2. Removal of links, groups
   3. Incremental updates
   4. Replay events

REST API

GET /relationships/

Parameters:

relation={IsSupplementedBy, Cites, IsCitedBy, IsIdenticalTo, HasVersions, IsVersionOf}
id=<string>  e.g.: "10.1234/some.doi.555"
scheme={doi,isbn,url,...}
groupby={version,identity}
size=<int>
page=<int>
sort={pubdate,author,title}
filter=<string>  (ES query)

[augustfly]

What is "DLI" test data?

[krzysztof]

Perhaps the "Test" is misleading. It's just a list of possible data sources for initial population (for testing), and perhaps as a nice initial dataset. DLI is this: http://scholexplorer.openaire.eu/

[augustfly]

oh, okay.

that scholexplorer UI reminds me why CrossRef's decision to focus on their Event Data API/data store and not roll out a UI was wise.

[augustfly]

At some point we may want to reconcile this with what we discussed in the October 2017 sprint, which @astrofrog started outlining here: https://github.com/orgs/asclepias/projects/1