IQSS
Dataset summary, continued
Originally from a comment I left at https://github.com/IQSS/dataverse-frontend/pull/112#issuecomment-1570889127, some items to follow up on after the original PR:
- #91
- Persistent Identifier is missing
- For Author
- For Point of Contact
- For privacy reasons, the email should be hidden. Instead we mention a button (that doesn't exist yet in the SPA). See also https://guides.dataverse.org/en/5.13/installation/config.html#email-privacy
- Affiliation should be in parentheses.
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 Phil's screenshot in the previous comment is of a test dataset that doesn't have metadata in those fields?
@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!
<tr id="metadata_persistentId">
<th scope="row">
#{bundle['dataset.metadata.persistentId']}
<span class="glyphicon glyphicon-question-sign tooltip-icon"
data-toggle="tooltip" data-placement="auto right" data-original-title="#{bundle['dataset.metadata.persistentId.tip']}"></span>
</th>
<td>#{globalId}</td>
</tr>
<tr id="metadata_alternativePersistentId" jsf:rendered="#{!empty altPID}">
<th scope="row">
#{bundle['dataset.metadata.alternativePersistentId']}
<span class="glyphicon glyphicon-question-sign tooltip-icon"
data-toggle="tooltip" data-placement="auto right" data-original-title="#{bundle['dataset.metadata.alternativePersistentId.tip']}"></span>
</th>
<td>#{altPID}</td>
</tr>
<tr id="metadata_publicationDate" jsf:rendered="#{!empty publicationDate}">
<th scope="row">
#{bundle['dataset.metadata.publicationDate']}
<span class="glyphicon glyphicon-question-sign tooltip-icon"
data-toggle="tooltip" data-placement="auto right" data-original-title="#{bundle['dataset.metadata.publicationDate.tip']}"></span>
</th>
<td>#{publicationDate}</td>
</tr>
<tr id="metadata_citationDate" jsf:rendered="#{!empty publicationDate and (publicationDate ne citationDate)}">
<th scope="row">
#{bundle['dataset.metadata.citationDate']}
<span class="glyphicon glyphicon-question-sign tooltip-icon"
data-toggle="tooltip" data-placement="auto right" data-original-title="#{bundle['dataset.metadata.citationDate.tip']}"></span>
</th>
<td>#{citationDate}</td>
</tr>
@pdurbin after checking all the missing points I have some comments:
For this point:
- For privacy reasons, the email should be hidden. Instead we mention a button (that doesn't exist yet in the SPA). See also https://guides.dataverse.org/en/5.13/installation/config.html#email-privacy
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
- ORCID there is no link (See also the [JSF side]
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 authorIdentifier field or any other specific metadata field. So having the ORCID link logic in the frontend doesn't make sense because I don't know that there is an authorIdentifier in the js-dataverse response.
The same happens for the message Use email above to contact, I need to know that a datasetContact is going to be retrieved by js-dataverse, which currently is impossible to know from the frontend perspective.
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:
- Persistent Identifier, Publication Date, Citation Date and Alternative Persistent Id
- Handle these fields in the frontend as part of this issue
- https://github.com/IQSS/dataverse-client-javascript/issues/66
- https://github.com/IQSS/dataverse-client-javascript/issues/65
- https://github.com/IQSS/dataverse-client-javascript/issues/64
- For Author No separation between name, affiliation, identifier type, and identifier. Affiliation should be in parentheses.
- Handle the tsvs in the frontend to read about the display format of the metadata fields. (In the tsvs we define the type of separation for each field)
- https://github.com/IQSS/dataverse-client-javascript/issues/63
- We'll probably need to extend the API because it doesn't seem to be retrieving the displayFormat of the tsv files https://guides.dataverse.org/en/latest/api/native-api.html#metadata-blocks-api
- ORCID there is no link (See also the https://github.com/IQSS/dataverse/pull/7979)
- We are going to handle this link creation in the backend so any new frontend can use it. We'll open an issue in the backend to extend the API to retrieve this ORCID link ( @GPortas )
- Handle this link format in the frontend
- For Point of Contact For privacy reasons, the email should be hidden. Instead we mention a button (that doesn't exist yet in the SPA). See also https://guides.dataverse.org/en/5.13/installation/config.html#email-privacy
- We need to handle this in the API, the email should not be retrieved for privacy reasons. We'll open an issue in the backend (@GPortas )
- Handle the datasetContact in the frontend to display the message 'Use email button above to contact'
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
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.
Yes, I agree. That would definitely be better.
Either way, I believe that the logic about the authorIdentifier link should be in the backend so any new frontend can use it
Yes, I agree with this too. Thanks for discussing after standup.
The conclusions look great. Thanks!