Closed davidschober closed 6 years ago
@cpd3149 - question:
So, we notice the same behavior in 7.2 as 7.3 where the Google scholar metadata does show up on the File, for example: https://arch.library.northwestern.edu/concern/parent/sj1391960/file_sets/6682x3948
But does not on the Work, for example: https://arch.library.northwestern.edu/concern/generic_works/sj1391960
We just wanted to clarify that this is not expected behavior.
Thanks.
@kdid -- good catch.
i'll have to investigate some more, but it seems strange that the citation_title
is pulling from the file name rather than the name of the work.
That's odd I thought I looked at the files themselves as well.
A couple of things:
I think it the pattern may have gotten a bit messy and may take some upstream conversations. Google Scholar expects a link to the full pdf, but a work can have multiple pdfs associated with it. It seems that if we're going to assume a journal article is a work (as opposed to say a journal issue being a work) that the work should have the citation information.
A few other things:
citation_title should be the title of the journal article, not the PDF. (Note A in the official guidelines)
citation_author should be the authors of the paper and allow for multiples. (Note B. in the official guidelines)
I thought Highwire themselves had docs for this stuff, but I'm not finding it.
Does someone want to kick off an upstream conversation? I'm thinking this may be unfinished work.
@davidschober -
After looking into this a little further, it seems like it's working as intended. (We didn't override something and break it)
(Note that the title of a file defaults to the filename but that title of the file is editable. If you do, that is what is used for citation_title.)
Since we're not modifying the defaults and we're using a Generic Work for any type of content anyone uploads we should have some further discussions about this.
EDIT: not sure the path matters. This Deep Blue Data example shows GS metadata, but pulls the filename for citation_title
and the depositor name for citation_author
instead of Creator.
i'd like to discuss the /concerns/generic_works/
structure vs. /files/
/files/
is used at PSU and DigitalHub. This PSU journal article is correctly pulling 'citation_title' from the user-entered Title field: https://scholarsphere.psu.edu/files/6682x4006
this is also the case for data: https://scholarsphere.psu.edu/files/cc08hf80f and dissertations: https://scholarsphere.psu.edu/files/sf268g73h
i think most deposits will be 1 file at a time (e.g. journal articles, dissertations, data), and the edge cases will be multiple files (e.g books).
Thanks @kdid. Let's mark this for discussion as it seems like there's no work to be done at this point.
Could you tell if citation_author is in fact pulling from depositor? That seems off.
Yes, holding a discussion about this would be a good idea.
@cpd3149 - just want to note that ScholarSphere has not yet migrated to Fedora4/Sufia7/PCDM and when they do their data structure will look more like ours. Peeking at their GitHub issues gives an idea. i.e. "Files" will become "GenericWorks" + "FileSets".
@davidschober - it does look like the creator in the metadata on the fileSet (but not the solr doc) is set to the user_key. This appears to be the same in Hyrax. Let me do a little more digging on why that might be so.
Just adding because these issues are both relevant to track how this plays out for Hyrax
Nice catch!
Anyone on the team can feel free to jump in and push changes upstream. Volunteers?
On Apr 3, 2017, at 12:12 PM, kdid notifications@github.com wrote:
Just adding because these issues are both relevant to track how this plays out for Hyrax
projecthydra-labs/hyrax#110 https://github.com/projecthydra-labs/hyrax/issues/110 projecthydra-labs/hyrax#109 https://github.com/projecthydra-labs/hyrax/issues/109 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/nulib/institutional-repository/issues/161#issuecomment-291209246, or mute the thread https://github.com/notifications/unsubscribe-auth/AElKnu-EaWgISngEXoJhpNvOXTtvhHF0ks5rsShkgaJpZM4MoyHk.
Looks like this was resolved upstream: https://github.com/samvera/hyrax/pull/1324
Cool. When they cut it let's grab it.
Sent from my iPhone
On Jul 10, 2017, at 8:34 AM, Chris Diaz notifications@github.com wrote:
Looks like this was resolved upstream: samvera/hyrax#1324
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
@csyversen This was resolved upstream, and we've deployed the latest version of hyrax, but it doesn't seem to be showing twitter/google scholar info on works. Can you check it out.
Investigate we can back port.
fixed in hyrax 2.x
Google Scholar/ Highwire style citation_ metadata fields in the header are not visible in arch. This should be on by default in a sufia instance. It's possible one of our views bonked it.
To Recreate:
Example:
This looks like should be populated by:
https://github.com/projecthydra/sufia/blob/818cb4ca53d81fdb37835a0cd7c753d66eacd679/app/views/layouts/_head_tag_content.html.erb#L8-L11
https://github.com/projecthydra/sufia/blob/818cb4ca53d81fdb37835a0cd7c753d66eacd679/app/views/shared/_citations.html.erb
Note, since we're upgrading to 7.3, can we grab this #160