-
Notifications
You must be signed in to change notification settings - Fork 16
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
Dataset summary, continued #115
Comments
Is "Persistent Identifier" missing because it's not in the citation.tsv file? And if that's the case, will other fields that aren't in the citation.tsv file but that appear in the Citation Metadata accordion (as of v5.13) be missing, too, like "Publication Date", "Citation Date", and "Previous Dataset Persistent ID"? Or are they missing because this screenshot is of a test dataset that's doesn't have metadata in those fields (like, it's not published, has no embargoed files and has no previous persistent ID)? |
@jggautier You're right, we were only looking at the citation.tsv I found this fragment in the JSF file with the fields you mention, so I'll add all of them to the SPA. Thanks!
|
@pdurbin after checking all the missing points I have some comments: For this point:
If the email should be hidden for privacy reasons then we need to asses this by extending the API and having an endpoint to get the dataset data without the email, otherwise I can hide the email in the frontend but anyone can intercept the api call made by js-dataverse and see the email. A part from that, I was looking at the JSF code to get the ORCID link
I'm treating metadataBlocks as black boxes since js-dataverse doesn't tell me anything about which specific metadataFields I can expect. And this is actually a great feature because it allows any customization of the metadataFields without altering the frontend. But this means that from the frontend perspective 'I cannot know' that there is going to be an The same happens for the message My suggestion is that we either treat citationMetadata as an explicit type, where the frontend can know what to expect from the citationMetadata, and then continue with the blackBox approach for the rest of the metadata fields. Or that we continue treating citationMetada as generic metadataFields, but in that case everything should be described by the tsvs in a generic way or retrieved by js-dataverse (ORCID link or email tip text) Either way, I believe that the logic about the authorIdentifier link should be in the backend so any new frontend can use it |
Some conclusions from the frontend meeting discussion:
I leave to @GPortas the priorization of these new issues in the SPA MVP backlog and I'll try to handle the modifications to the frontend in this same issue |
Resized to 33 during sprint to reflect new analysis. |
Yes, I agree. That would definitely be better.
Yes, I agree with this too. Thanks for discussing after standup. The conclusions look great. Thanks! |
Originally from a comment I left at #112 (comment), some items to follow up on after the original PR:
The text was updated successfully, but these errors were encountered: