Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Abstract view type" checking is very naive #41

Open
haydenmccormick opened this issue Jun 18, 2024 · 1 comment
Open

"Abstract view type" checking is very naive #41

haydenmccormick opened this issue Jun 18, 2024 · 1 comment

Comments

@haydenmccormick
Copy link
Collaborator

Because

Views are rendered as appropriate tabs by attempting to ascertain the "abstract view type", e.g. OCR, ASR, NER, etc. This is done extremely naively, especially when checking for OCR views, since there is no standardized schema for what the output of a "thumbnail" view should look like. For example, these views could output:

As a Band-Aid solution, the OCR abstract view type checker just pattern matches against known OCR/CV apps to determine if a view is a thumbnail tab. This is obviously not great for long-term development, since it would require the list to be manually updated with every new OCR app, and it wouldn't support third-party (non-CLAMS-developed) apps.

Done when

This could be addressed in a few different ways:

  1. A standardized "abstract view type" as part of the metadata for MMIF views, defined by each CLAMS app separately
  2. Allowing the user to add views as tabs manually and specify their abstract type from within the app
  3. A much more advanced rule-based type checking system (if there is some consistent and maintained pattern)

There are most likely other solutions that may be more elegant/robust -- I'm leaving this issue open for further discussion on potential strategies/methods for dealing with this problem

Additional context

No response

@clams-bot clams-bot added this to infra Jun 18, 2024
@github-project-automation github-project-automation bot moved this to Todo in infra Jun 18, 2024
@keighrim
Copy link
Member

I believe this issue to be elevated to the SDK level.


I like the idea#1. We can pre-define "app patterns" in clams-python SDK, and each individual app can be subclass(es) of this app patterns (explicitly displayed in app metadata maybe). We can then re-use the app patterns for evaluation repo. Currently we have arbitrary "themes" used in evaluation subdirectories, so we can start from them, incrementally expand the list of patterns, while roughly maintaining the (loose) alignments to the evaluation themes.

@MrSqually I remember you had at some point a similar idea while working on evaluation automation. Can you post your notes from the previous discussion here as well?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Todo
Development

No branches or pull requests

2 participants