| Status | Assigned | Task | ||
|---|---|---|---|---|
| Open | vlorentz | T2064 Add metadata from deposits to metadata search | ||
| Work in Progress | vlorentz | T3097 Expose metadata in the WebApp and make it searchable | ||
| Open | vlorentz | T2073 Index extrinsic metadata from the journal in swh-search/Elasticsearch | ||
| Resolved | vlorentz | T2074 Publish extrinsic metadata to swh-journal/Kafka | ||
| Resolved | vlorentz | T2075 Implement metadata authority specification | ||
| Resolved | vlorentz | T1737 Define and specify metadata providers | ||
| Resolved | vlorentz | T2343 Decide where/how to store extrinsinc metadata | ||
| Resolved | vlorentz | T2306 Generic storage for extrinsic, qualified metadata related to any node of the swh archive | ||
| Resolved | vlorentz | T2876 metadata indexation : ES' dynamic mapping creation fails for field values that are of varying types |
Event Timeline
Comment Actions
I don't think we're "resolving" T2063 until we need to process tasks that can't reasonably be handled by celery. On the other hand, journal clients are sort of a resolution to T2063.
Would a "simple" journal client, which would be able to mangle known metadata types into something that can be fed into elasticsearch be appropriate here?
Comment Actions
On the other hand, journal clients are sort of a resolution to T2063.
Yes, they are. I just want to make sure we explicitly decide to go that way.
Would a "simple" journal client, which would be able to mangle known metadata types into something that can be fed into elasticsearch be appropriate here?
Yes.