diff options
| -rw-r--r-- | notes/2021_09_review.md | 129 | ||||
| -rw-r--r-- | notes/Makefile | 9 | ||||
| -rw-r--r-- | notes/known_issues.md | 17 | ||||
| -rw-r--r-- | notes/todo_manual_review.md (renamed from notes/todo.md) | 0 | ||||
| -rw-r--r-- | notes/workflow_schema.dot (renamed from notes/steps.dot) | 0 | ||||
| -rw-r--r-- | notes/workflow_schema.png (renamed from notes/steps.png) | bin | 29268 -> 29268 bytes |
6 files changed, 153 insertions, 2 deletions
diff --git a/notes/2021_09_review.md b/notes/2021_09_review.md new file mode 100644 index 0000000..f15ed5b --- /dev/null +++ b/notes/2021_09_review.md @@ -0,0 +1,129 @@ +# Fuzzy matching review and retrospective + +> 2021-09-15 + +After [refcat](https://gitlab.com/internetarchive/refcat) has reached a +milestone, I'd like to review fuzzycat and fuzzy matching in general; this +should help pave the way to a slight redesign of the overall approach. + +## TL;DR + +* performance matters at scale and a faster language (e.g. Go) is essential +* for small scale, the api matters more than performance +* a lot of the code currently is base on specific schemas (e.g. release, a + specific elasticsearch mapping, etc), so not that much code is generic or + reusable - it also seems overkill to try to abstract the schema away + +## Ideas + +* [ ] use pydantic or dataclass to make schema more explicit +* [ ] extend type annotation coverage +* [ ] remove bulk stuff, remove clustering etc; improve the verification part +* [ ] use cases: work merging + +A few more things to revisit: + +* [ ] revisit journal matching; what is weak, strong? +* [ ] refactor: author list or string comparison +* [ ] go beyond title matching when querying elasticsearch +* [ ] better container name matching + +Take a look at: + +> https://github.com/djudd/human-name + +---- + +## Redesign ideas + +### Large scale processing + +JSON decoding and encoding does not seem to be the bottleneck, but working with +various, often optional fields gets expensive in Python (whereas in Go, we can +use a struct). + +The mapping stage in +[refcat/skate](https://gitlab.com/internetarchive/refcat/-/blob/3a79551dfe54ba668f7eee9de88625a0d33d9c7f/skate/map.go#L109-111) +is a simple operation (blob to fields), that can be implemented in isolation +and then [added to the command +line](https://gitlab.com/internetarchive/refcat/-/blob/3a79551dfe54ba668f7eee9de88625a0d33d9c7f/skate/cmd/skate-map/main.go#L67-87). +In skate, we already have over a dozen mappers working on various types. +There's even a bit of [map +middleware](https://gitlab.com/internetarchive/refcat/-/blob/3a79551dfe54ba668f7eee9de88625a0d33d9c7f/skate/map.go#L152-161). + +In fuzzycat, the +[Cluster](https://git.archive.org/webgroup/fuzzycat/-/blob/c587a084defe54103aa147b7ab91542a11a548b1/fuzzycat/cluster.py#L309-347) +class does mapping, via +[key](https://git.archive.org/webgroup/fuzzycat/-/blob/c587a084defe54103aa147b7ab91542a11a548b1/fuzzycat/cluster.py#L331), +[sorting](https://git.archive.org/webgroup/fuzzycat/-/blob/c587a084defe54103aa147b7ab91542a11a548b1/fuzzycat/cluster.py#L406-426), +and a specific +[grouping](https://git.archive.org/webgroup/fuzzycat/-/blob/c587a084defe54103aa147b7ab91542a11a548b1/fuzzycat/cluster.py#L428-454) +all in one go. + +For example, we did not use the single cluster document in refcat/skate anymore +(there, we keep two separate files and use an extra +[zipkey](https://gitlab.com/internetarchive/refcat/-/blob/3a79551dfe54ba668f7eee9de88625a0d33d9c7f/skate/zipkey/zipkey.go#L23-33) +type, which is a slightly generalized +[comm](https://en.wikipedia.org/wiki/Comm), e.g. it allows to run a function +over a cluster of documents (coming from currently two streams). + +A higher level command could encapsulate the whole pipeline, without needed an extra framework like luigi: + + inputs A B + | | + mapped M1 M2 + | | + sorted S1 S2 + \ / + \ / + reduced V + | + | + C + +> Not sure, if we need mappers at all, if we have them in refcat. + +An a command could look like this. + + $ fuzzycat pipeline -a A.json -b B.json --mapper-a "tn" --mapper-b "tn" --reduce "bref" + +Nice, if this would actually run fast. Could also be run programmatically: + + output = fuzzycat_pipeline(a="A.json", b="B.json", mapper_a="tn", mapper_b="tn", reduce="bref") + +Mappers should have a minimal scope; each mapper will have a format it can work +on. Reducers will have two inputs types specified. + +### Running continuously + +> With a couple of the inputs (metadata, extracted data, ...) getting updated +> all the time, it might for the moment be simpler to rerun the derivation in +> batch mode. + +A list of steps we would need to implement for continuous reference index updates: + +* a new metadata document arrives (e.g. via "changelog") +* if the metadata contains outbound references, nice; if not, we try to download the associated PDF, run grobid and get the references out that way + +At this point, we have the easier part - outbound references - covered. + +Where do the outbound references of all existing docs live? In the database +only, hence we cannot search for them currently. + +* [7ppmkfo5krb2zhefhwkwdp4mqe](https://search.fatcat.wiki/fatcat_release/_search?q=ident:7ppmkfo5krb2zhefhwkwdp4mqe) + says `ref_count` 12, but the list of refs we can only get via + [api](https://api.fatcat.wiki/v0/release/7ppmkfo5krb2zhefhwkwdp4mqe) + +We could add another elasticsearch index only for the raw refs. E.g. everytime +an item is updated, this index gets updated as well (taking refs from the API +and put them into ES). We can then query for any ID we find in the reference or +any string match, etc. Once we find e.g. ten documents, that have the document +in question in their reference list, we can update the reference index for each +of these documents. + +We could keep a (weekly) refs snapshot file around that would be used for +matching. The result would be the e.g. ten document, that refer to the document +in question. We can take their ids and update the document to establish the +link. The on-disk file (or files) should be all prepared, e.g. sorted by key, +so the lookup will be fast. + diff --git a/notes/Makefile b/notes/Makefile index 3a7dcaf..b4996f9 100644 --- a/notes/Makefile +++ b/notes/Makefile @@ -1,6 +1,11 @@ -steps.png: steps.dot +TARGETS = workflow_schema.png + +.PHONY: all +all: $(TARGETS) + +%.png: %.dot dot -Tpng $^ > $@ .PHONY: clean clean: - rm -rf steps.png + rm -rf $(TARGETS) diff --git a/notes/known_issues.md b/notes/known_issues.md index 32194fd..991de5c 100644 --- a/notes/known_issues.md +++ b/notes/known_issues.md @@ -102,3 +102,20 @@ $ python -m fuzzycat verify_single | jq . ] } ``` + +## "jaccard authors" can be too weak + +``` +$ python -m fuzzycat verify_single | jq . +{ + "extra": { + "q": "https://fatcat.wiki/release/search?q=canes" + }, + "a": "https://fatcat.wiki/release/ivhoiqvjt5cpxbdzzbuco7eciq", + "b": "https://fatcat.wiki/release/hprvn76ls5cbbkl2ypsyijojmu", + "r": [ + "strong", + "jaccard_authors" + ] +} +``` diff --git a/notes/todo.md b/notes/todo_manual_review.md index b3474f8..b3474f8 100644 --- a/notes/todo.md +++ b/notes/todo_manual_review.md diff --git a/notes/steps.dot b/notes/workflow_schema.dot index 365163f..365163f 100644 --- a/notes/steps.dot +++ b/notes/workflow_schema.dot diff --git a/notes/steps.png b/notes/workflow_schema.png Binary files differindex b321976..b321976 100644 --- a/notes/steps.png +++ b/notes/workflow_schema.png |
