Altmetrics on DSpace 6

[Cameron, Jacob]

Hello Everyone,

 

We are running DSpace 6.0 with Postgres and Tomcat.

 

I’ve enabled Altmetrics in the altmetrics.cfg, we are being being tracked by Altmetrics and have ports 80 and 443 open to http://api.altmetric.com but stats are not showing up for items that have stats on our DSpace instance. (https://www.altmetric.com/details/9020018, http://hdl.handle.net/10133/3376)

 

Any suggestions on how what to look at next?  I’ve checked the item-view.xsl and all of the proper code appears to be there for getting Altmetrics to display.

 

Jake

 

--

Jake Cameron, BCS(UNB)

Systems Support Specialist III

Information Systems and Technical Services University of Lethbridge Library

Phone:(403)329-2756

 

This e-mail, including any and all attachments, is only for the use of the intended recipient(s) and may contain information that is confidential or privileged. If you are not the intended recipient, you are advised that any dissemination, copying or other use of this e-mail is prohibited. Please notify the sender of the error in communication by return e-mail and destroy all copies of this e-mail.  Thank you.

 

[Kim Shepherd]

Hi Jacob, hmm,  I think there are a few things going on here...

1. I've figured out that the configuration properties for altmetric aren't being loaded properly by Mirage -- that's fixed with a pretty easy PR and wouldn't be hard to patch your instance. (just replacing things like confman:getProperty("altmetrics", "altmetric.enabled") with confman:getProperty("altmetric.enabled") )

2. Further, the variables relied on to get identifiers ($identifier_handle and $identifier_doi) are not being created properly in global-variables.xsl because it doesn't have access to item metadata in that context. I think the best thing to do for this is for us to create these variables in somewhere like item-view.xsl which has access to all the item metadata.

3. A couple of extra issues with $identifier_handle -- it's looking in a field called dc.identifier.handle which doesn't exist by default (most of us use dc.identifier.uri) and isn't reading the altmetrics.field config property to see which field you've actually told the altmetric badge to use. Also, for handles, altmetric expects just the prefix/identifier in the "data-handle" attribute, not the full URI so we'll have to try and strip that out too (ie. yours should be passed as 10133/3376) when creating the $identifier_handle variable

I'll keep testing (I have managed to get the badge displaying properly when I fix the config property stuff and hardcode your handle instead of relying on the variables) but I think best steps are: I'll submit a PR to fix the config issues, I'll figure out where and best DRI path to access identifier metadata is for variables to use with altmetric/plum badges, tell said variable to look at altmetrics.field to make sure it is looking in the right field, and if it's expecting a handle, strip out everything before the prefix.

4. You might have trouble loading the JS in on your site anyway, based on something else I saw:

The browsers I try are blocking jquery from being loaded because it's trying to load from the Google CDN with http:// whereas your site is secure under https://

(most modern browsers will now block this kind of mixed/insecure content loading)

XMLUI does attempt to compile the correct scheme (http or https) into the URL for javascript loading (see https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-xmlui/src/main/webapp/themes/Mirage/lib/xsl/core/page-structure.xsl) so I think XMLUI must think that your base URL starts with http:// and not https://

One reason for this could be that your site is sitting behind some frontends/appliances which handle the SSL endpoint and then offload traffic to your backend application servers running on http:// -- does this sound like it could be the case? If so, the fix might be as simple as finding the line in page-structure.xsl that compiles the javascript script element:

<script type="text/javascript" src="{concat($scheme, 'ajax.googleapis.com/ajax/libs/jquery/', $jqueryVersion ,'/jquery.min.js')}">&#160;</script>

...and tell it to just use relative scheme regardless, eg.

<script type="text/javascript" src="{concat('//ajax.googleapis.com/ajax/libs/jquery/', $jqueryVersion ,'/jquery.min.js')}">&#160;</script>

The plain "//" will look at what the browser sees rather than what XMLUI thinks is your base scheme, so it should load jquery securely. 

Now that's not directly related to altmetric but the altmetric JS is loaded in the same way:

<script type="text/javascript" src="{concat($scheme, 'd1bxh8uas1mnw7.cloudfront.net/assets/embed.js')}">&#xFEFF;
	</script>

So if you have to keep your xmlui base URL as http:// in your DSpace config but serve it over https:// you can force this to also use a relative scheme like:

<script type="text/javascript" src="{concat(,'//d1bxh8uas1mnw7.cloudfront.net/assets/embed.js')}">&#xFEFF;
</script>

I wonder if we should think about forcing $scheme everywhere to be '//' instead of trying to figure it out from config -- I think that might break compatibility with some older IE versions, but not sure if I'm remembering correctly.

Hope this helps! Will let you know what else I figure out and if anyone reading this can chip in with a good place/full DRI path to get the identifiers out and into a variable, that'd be great, my XMLUI has gotten rusty and ./mets:dmdSec/mets:mdWrap[@OTHERMDTYPE='DIM']/mets:xmlData/dim:dim/dim:field[@element='identifier'][@qualifier='uri'] for instance doesn't grab it...

Cheers

Kim

[Kim Shepherd]

Hi Jacob and all,

Further to this, I figured out how that page metadata is actually generated and then read into a variable in the XMLUI template, so the issue wasn't as complicated as I thought -- it's basically all down to that #1 issue I identified, not the others.

I've logged a JIRA ticket for the problem at https://jira.duraspace.org/browse/DS-3477 and my pull request for the fix is at https://github.com/DSpace/DSpace/pull/1637. Still need to test with DSpace 5 (the configurationmanager changes could mean it only applies to 6). If you grab that pull request and try it out in your dev environment, you'll hopefully see the badges.

You may still run into scope trouble with the http vs https javascript references in which case the scheme changes to '//' from #4 in my earlier reply should fix up the scheme mismatch.

Hope this helps!

Cheers

Kim

--
You received this message because you are subscribed to a topic in the Google Groups "DSpace Technical Support" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dspace-tech/xt23Oy61qVc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dspace-tech+unsubscribe@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[Cameron, Jacob]

That did the trick.  It is showing up on my development server properly now.

 

--

Jake Cameron, BCS(UNB)

Systems Support Specialist III

Information Systems and Technical Services University of Lethbridge Library

Phone:(403)329-2756

 

This e-mail, including any and all attachments, is only for the use of the intended recipient(s) and may contain information that is confidential or privileged. If you are not the intended recipient, you are advised that any dissemination, copying or other use of this e-mail is prohibited. Please notify the sender of the error in communication by return e-mail and destroy all copies of this e-mail.  Thank you.

 

Kim

--

To unsubscribe from this group and all its topics, send an email to dspace-tech...@googlegroups.com.

To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

 

--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.