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

Set MVM PROPOSID keyword in MVMs to list of proposal ids #1735

Open
stscijgbot-hstdp opened this issue Feb 14, 2024 · 3 comments
Open

Set MVM PROPOSID keyword in MVMs to list of proposal ids #1735

stscijgbot-hstdp opened this issue Feb 14, 2024 · 3 comments

Comments

@stscijgbot-hstdp
Copy link
Collaborator

Issue HLA-1207 was created on JIRA by Matthew Burger:

Currently if users search in MAST by proposal number they will not get the MVMs included in their search results. The HSTMO would like to see this changed if possible. (If the SVMs are added to the download basket, they will see the MVMs also). Before we work this we need to determine if CAOM can resolve a list in this field.

@stscijgbot-hstdp
Copy link
Collaborator Author

Comment by David Rodriguez on JIRA:

Some comments from my email:

I believe that the way we handle it for TESS is that we concatenate the results with an underscore, so something like {}G04208_G04098{}. That said, I notice that other things that are multi-valued, like filters, are delimited by semi-colons and that makes them easier to use by the Portal (eg, {}FQCH4P15;F467M;F300W{}).

I would want CAOM to investigate which option is better before committing to one, though we can transform one to the other relatively easily.

 

I do want to point out a couple of things we should keep in mind:

1 Portal handling of the field

This is a string field and I don’t believe it is currently parsed by the Portal to split them. For example, a search on G04098 would only return values that exactly match that. If you wanted to search for observations that contain it you need to add some wildcards: G04098 (perhaps that argues for always wildcarding but that may come with its own issues)
I do notice that the filter column (which is semi-colon delimited) has values that get split in the side panel so that could be an argument for adopting that delimiter, but don't know what happens with advanced searches.

 

2 Links back to proposal page

HST proposal IDs link back to a page with the proposal details, for example: https://archive.stsci.edu/proposal_search.php?mission=hst&id=2686
Is that something we would need to continue doing? I think that will pose some challenges when we store multiple cases and we’ll need to work with the UI folks on that.

 

3 Archive Partner handling

We should review this change with the Archive Partners ahead of implementing it.
Multiple proposal ids are technically not supported by CAOM- we are hacking the model to support them for things like TESS. If we start to do this for HST we could cause them issues on their end.

 

4 MissionMast support

Your initial message mentions the Portal, I don’t remember/know if the multi-visit mosaics are in MissionMast yet but if/when they are that may introduce some considerations we’ll want to keep in mind. Likely whether searches use wildcards or including proposal links.

@stscijgbot-hstdp
Copy link
Collaborator Author

Comment by Lisa Sherbert on JIRA:

Is it important that it be the PROPOSID keyword that contains a list? Seems like that would slightly change its meaning. But PROPOSID is already 8-char, so we cannot just make it plural. Maybe it is ok that PROPOSID mean something slightly different in MVM headers. Just something to consider.

@stscijgbot-hstdp
Copy link
Collaborator Author

Comment by David Rodriguez on JIRA:

On the CAOM end, we've decided that we'll be adopting a semicolon delimited list (we'll backfill/correct any other missions that used underscores or other characters).

CAOM can adapt based on how you decide to store that information; if it's a single keyword (whether PROPOSID or a different keyword) that contains a string with semicolon-delimited values that would be the easiest, but if it's encoded in a table in another extension we can likely code up how to access it. 

We'll also need to make UI changes and chatted about that on our end, but that would be handled by another team.

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

No branches or pull requests

1 participant