Project

General

Profile

Actions

Feature #5490

closed

Ability to embed DC or COinS metadata

Added by Stephen Klein almost 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority name:
High
Assignee:
Daniel Jones
Category name:
WordPress (misc)
Target version:
Start date:
2016-04-25
Due date:
% Done:

0%

Estimated time:
6.00 h
Deployment actions:

Description

JITP needs the journal to have the ability to successfully embed Dublin Core or COinS metadata, so readers of JITP:
http://jitp.commons.gc.cuny.edu/

can use citation tools such as Zotero:
https://www.zotero.org/
to extract Dublin Core:
http://dublincore.org/documents/dces/
or COinS metadata:
https://en.wikipedia.org/wiki/COinS
to successfully generate accurate citations.

I tried using ScholarPress plugin:
https://wordpress.org/plugins/scholarpress-coins/
and was not successful
Zotero still used the person who posted the article and did not allow for editing of the metadata.

I also tried:
https://wordpress.org/plugins/dublin-core-metadata/
https://wordpress.org/plugins/dublin-core-for-wp/
https://wordpress.org/plugins/wordpress-publication-repository/

Using a cue from Kairos:
http://kairos.technorhetoric.net/20.2/topoi/miller-et-al/index.html
where DC metadata is embedded:
view-source:http://kairos.technorhetoric.net/20.2/topoi/miller-et-al/index.html
<!--BEGIN Dublin Core Metadata-->
<meta name="DC.title" content="The Roots of an Academic Genealogy: Composing the Writing Studies Tree" />
<meta name="DC.creator" content="Benjamin Miller" />
<meta name="DC.creator" content="Amanda Licastro" />
<meta name="DC.creator" content="Jill Belli" />
<meta name="DC.type" content="Text" />
<meta name="DC.format" content="text/html" />
<meta name="DC.language" content="en" />
<meta name="DC.subject" content="writing studies, genealogy, networks, scholarship, pedagogy" />
<meta name="DC.publisher" content="Kairos: A Journal of Rhetoric, Technology, and Pedagogy" />
<meta name="DC.source" content="20.2" />
<meta name="DC.isPartOf" content="Topoi" />
<meta name="DC.date" content="2016-01-01" />
<meta name="DC.identifier" content="http://kairos.technorhetoric.net/20.2/topoi/miller-et-al/index.html"/>
<!--END Dublin Core Metadata-->

And Zotero is successfully able to extract info, I pasted same metadata into a Wordpress post via text, but Wordpress stripped, so then I installed the RAW plugin: https://wordpress.org/plugins/raw-html/ and pasted dublin core metadata again, but, again Zotero was not able to correctly extract metadata.

I am attaching a standalone html page with Dublin Core metadata embedded that I was successfully able to use Zotero with.


Files

dc.html (1.8 KB) dc.html Stephen Klein, 2016-04-25 10:42 AM
1.jpg (148 KB) 1.jpg Stephen Klein, 2016-06-07 11:51 AM
2.jpg (147 KB) 2.jpg Stephen Klein, 2016-06-07 11:51 AM

Related issues

Related to CUNY Academic Commons - Bug #3300: zotero translator treats single article as folderDuplicateDaniel Jones2014-07-09

Actions
Related to CUNY Academic Commons - Feature #6435: ScholarPress COinS should support multiple values for some DC fieldsResolvedDaniel Jones2016-10-24

Actions
Actions #1

Updated by Matt Gold over 6 years ago

  • Category name set to WordPress (misc)
  • Status changed from New to Assigned
  • Assignee changed from Matt Gold to Boone Gorges

Boone, can you please take a look at this? Thank you

Actions #2

Updated by Boone Gorges over 6 years ago

  • Assignee changed from Boone Gorges to Daniel Jones
  • Target version set to 1.10

Previously: #3300.

Stephen, when you say that you tried https://wordpress.org/plugins/dublin-core-metadata/screenshots/, I assume you mean that you tried and it did not work. Can you specify the way in which it didn't work? Did the plugin load at all? Or did it not output the DC metadata to the page? Or was Zotero unable to read it?

Following up on #3300, there appear to be no existing plugins (aside from dublin-core-metadata) that allow for the creation of custom COinS or DC metadata. So, in order to support Stephen's request, we're going to need to build something ourselves. I've talked with Matt about it and we agree that it's a worthwhile project.

Dan, I'd like you to take the lead on this. You've got some experience thinking about exposing this kind of data to Zotero, and I think it'll be a fun project.

Since we are friends with the folks at RRCHNM, and since the plugin is already active on the Commons, I'd like to suggest that we use scholarpress-coins as a starting point. I'll start a conversation with those folks about the possibility of taking over the plugin officially. But in the meantime, let's start with that very simple plugin as a base. We'll maintain backward compatibility with the current plugin by using the existing values as fallbacks when no custom metadata has been provided. What you'll add is (a) some interface on the Dashboard for entering metadata (maybe a custom metabox? Use your imagination), (b) some logic for saving and sanitizing the data, and (c) the functionality that dynamically outputs the saved metadata.

Dan, is this enough information to get started?

Actions #3

Updated by Stephen Klein over 6 years ago

Sorry, for the ambiguity.

Yes, this plugin did previously successfully install:
https://wordpress.org/plugins/dublin-core-metadata/
but it did not allow for the writing of meta-data to posts or pages.

I just tested against a different theme and it actually does allow for the writing of meta-data, however it does not allow for real DC.
Look at this post:
http://www.gclibrarytest.org/blog/2015/12/22/holiday-surprise-free-nytimes-pass-now-includes-tablet-app/
all that it inserts is:
<div class="entry-content">
Isaac Sanchez
Test Posting
JITP </div><!-- .entry-content -->

But, it should look something like:
<!--BEGIN Dublin Core Metadata-->
<meta name="DC.creator" content="Isaac Sanchez />
<meta name="DC.title" content="Test" />
<meta name=""DC.publisher" " content="JITP" />
<!--END Dublin Core Metadata-->

I suggest that the ScholarPress plugin is built out, allowing for the writing of DC meta-data in the dashboard similar to the Dublin Core one.

Actions #4

Updated by Boone Gorges over 6 years ago

A quick update that I've spoken with the folks who developed and maintain the ScholarPress Coins plugin, and they're happy to hand the keys over to us for the proposed improvements.

Dan, the repo is here https://github.com/scholarpress/scholarpress-coins/. Let's call the next release 2.0. I've started a branch https://github.com/scholarpress/scholarpress-coins/tree/2.0.x where work should happen toward this release.

Let me know if you have questions getting started.

Actions #5

Updated by Daniel Jones over 6 years ago

Here's my first crack at adding the ability to customize the data: https://github.com/scholarpress/scholarpress-coins/commit/9a7b1f20744cc0421ac190b61463a9cbeae73c88

I think one of the next things I'd want to do is add a "restore defaults" button/link. Right now there's no way to get back to the default values once you delete/change them, except manually.

Let me know what you think of it all.

Actions #6

Updated by Stephen Klein over 6 years ago

Matt and Boone,

Can we have uploaded to the Commons, so I can test against:
http://jitpdev.commons.gc.cuny.edu/

Thank you.

Actions #7

Updated by Stephen Klein over 6 years ago

Thanks.

Is the intention for folks to generate their own COinS metdata?

I see that the readme states:
'The plugin will automatically add an empty `<span>` to each post and page with COinS data.'
So is the assumption that the user needs to create COinS data for each page within the editing space of the page?

I was able to grab some COins via:
https://www.zotero.org/support/dev/exposing_metadata/coins
but if already in Zotero, then we do not really need this plugin.

I was thinking that there would be an editing interface on the that enables the adding of the metadata in the post/page editor and then the plugin converts to COins and exposes the COins.

As in my example below, COins is not the easiest type of metadata to create:
<span class='Z3988' title='url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fzotero.org%3A2&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Review%20of%20America's%20Half-Century%3A%20United%20States%20Foreign%20Policy%20in%20the%20Cold%20War&rft.jtitle=Presidential%20Studies%20Quarterly&rft.stitle=Presidential%20Studies%20Quarterly&rft.volume=23&rft.issue=3&rft.aufirst=Jonathan&rft.aulast=Nashel&rft.au=Jonathan%20Nashel&rft.au=Thomas%20J.%20McCormick&rft.date=1993&rft.pages=586-588&rft.spage=586&rft.epage=588&rft.issn=0360-4918'></span>

Actions #8

Updated by Daniel Jones over 6 years ago

Sorry that was my mistake, not updating the Readme.

The old version of the plugin only does it automatically, this new one both generates some defaults and exposes the kind of interface you're talking about on posts and pages to override the defaults.

Actions #9

Updated by Stephen Klein over 6 years ago

Please see the attached files. I do not see the ability to edit the metadata.

Actions #10

Updated by Daniel Jones over 6 years ago

Have you tried it on a post as well? Sorry about that - for testing I enabled it just on posts, and forgot to change it back.

Actions #11

Updated by Stephen Klein over 6 years ago

Yes, using the default 'Twenty Sixteen' theme.

Actions #12

Updated by Daniel Jones over 6 years ago

Is it possible that you pulled in the "master" branch of the repository, instead of 2.0.x, which is our development branch where the changes have been made?

Actions #13

Updated by Stephen Klein over 6 years ago

Mea culpa. I see the editor now. Sorry, I forgot that this project was forked.

Actions #14

Updated by Stephen Klein over 6 years ago

Wondering if the editor needs multiple creator fields (at least 3), Publisher (journal name) and Issue.

Matt, do you have an opionion?

Actions #15

Updated by Matt Gold over 6 years ago

that sounds reasonable to me, Stephen

Actions #16

Updated by Stephen Klein over 6 years ago

Thanks, Matt.

Daniel, can you add:
2 more creator fields.
Publisher field.
Issue field

Thank you.

Actions #17

Updated by Boone Gorges over 6 years ago

Thanks, Dan! I will have a look this week.

Stephen, we'll be unable to add this to the Commons until it's had a thorough review; we can't introduce it before the data model is set, or users may enter data that won't work once the final version is in place. If you'd like to test on your own WordPress installation while we're in active development, you can download the plugin from Github.

Actions #18

Updated by Boone Gorges over 6 years ago

Hi Dan - Finally getting a chance to look this over. In general, the changes look good. A couple of smallish things, which I'll raise on Github.

Biggest problem I see is that your rewrite doesn't maintain full compatibility with the existing plugin. You've written it in such a way that a post without any saved COinS data will put a bunch of empty fields in the Z3988 span. Any newly created post, or any existing post that is re-saved, will have this data generated. But this causes problems for existing posts that will not have been resaved after update.

I suggest introducing a new function, named something like scholarpress_coins_get_post_data(). Internally, it will do all of the fallback logic you're currently doing in scholarpress_coins_add_coins_meta_box() - the $default_coins_data stuff. Then, use that function both when generating the meta box, and when generating the span on the front end. In this way, the logic is centralized, and even posts that are not resaved will continue to have the fallback values shown after the upgrade to scholarpress-coins 2.0.

Actions #19

Updated by Daniel Jones over 6 years ago

Thanks Boone! That's a good point about pre-existing posts. The reason I built it that way originally was in case, for some reason, a user wanted to not include some of the fields that we generate default data for. If we also generate it when we're making the span, that default data will always be included. I think it's worth it though, given what you've said here. We should find some way of letting the user know that'll happen though, so that it's expected behavior.

Maybe we can add a checkbox option to just hide all COinS data for a post/not generate the span instead. We could also include a message like "Fields with a * will be filled automatically from your post's information is left blank." or something.

Actions #20

Updated by Boone Gorges over 6 years ago

The reason I built it that way originally was in case, for some reason, a user wanted to not include some of the fields that we generate default data for.

Ah, I guess this means the new fields that have been added? Because previously, all fields were generated, whether the user wanted them or not.

You could bake the distinction between "legacy" fields (which should be filled with default values) and non-legacy fields, into the scholarpress_coins_get_post_data() utility function I've suggested. In the case of "legacy" fields, you would only backfill with default data if you don't find anything in the postmeta table corresponding to the field; if you find the "empty" value (this is what you're using 'scholarpress_coins_empty' for), you wouldn't render the field. In this way, users would be able to disable a field by deleting the suggested value when saving the post, and leaving it blank. In the case of non-legacy fields, it may make sense not to show them at all until they've been saved, for complete equivalence with the previous plugin behavior. Does that seem right?

Actions #21

Updated by Stephen Klein over 6 years ago

Boone's suggestion makes sense to me.

Actions #22

Updated by Daniel Jones over 6 years ago

Thanks for this, Boone. Here's my attempt to ensure compatibility with version 1: https://github.com/scholarpress/scholarpress-coins/commit/2a8721ed7f1e5263511c1068669c4b9179847d67

I think I'm going to add the "Set to defaults" button next, and then work on the other requested fields.

This seems important to me because right now, if you change the post's title (including changing it from empty to adding something) or categories and update it, it doesn't update the COinS data at all. I think this is the right behavior, but I want to give users a one-click way to update the COinS info to reflect changes they've made to the post, or to just do a reset. This'll mean, however, that changes to the other fields, like author will also be overwritten and set the the defaults. I think it's worth it though to give users the option. Let me know what you think though.

Another option would be to add a checkbox or something next to each field that could say something like "always use default value," which would disable the field and always try to pull in the information from the post data.

Actions #23

Updated by Stephen Klein over 6 years ago

Checkbox for each field would provide most flexibility.

Actions #24

Updated by Boone Gorges over 6 years ago

Thanks for your continued work on this, Dan. Sorry for the delay in my review.

The new technique for backward compatibility fallback values is good. There was a typo in a variable name that was causing these fields not to be rendered properly, which I fixed in https://github.com/scholarpress/scholarpress-coins/commit/fa8410fe48c1209c0237b9589fb5bad56188f728.

I made some general improvements to the way the admin metabox form is built, which you can see in https://github.com/scholarpress/scholarpress-coins/commit/01d7723cfd63320f0f0e6080d976b16e43c29939. I also added XSS protection on the front end in https://github.com/scholarpress/scholarpress-coins/commit/c00d94c23a5b168a556cc817cc87dc8f5757f187.

if you change the post's title (including changing it from empty to adding something) or categories and update it, it doesn't update the COinS data at all. I think this is the right behavior, but I want to give users a one-click way to update the COinS info to reflect changes they've made to the post, or to just do a reset. This'll mean, however, that changes to the other fields, like author will also be overwritten and set the the defaults. I think it's worth it though to give users the option. Let me know what you think though.

Yeah, this is tricky. I agree that the current behavior is correct - it's good to default to the values that users have manually entered. A per-field "always use defaults" field seems like a decent compromise to me. Maybe the language/UI can use a "lock" metaphor: the field is "locked" to the post field. Then the input would be disabled.

In an ideal world, you'd also have some JS that detects changes to the post fields in question, and updates the disabled fields automatically - this will avoid confusion when a user changes the title, but hasn't yet saved the page, and the DC title field still reads something else. This definitely does not have to be done for v1, but might be a fun little project.

Let's get the lock/sync mechanism in, and we can roll the plugin as a work-in-progress onto the Commons.

Actions #25

Updated by Daniel Jones over 6 years ago

  • Estimated time set to 6.00 h

I've taken a first pass at the field locking - I had done some work on it on a local branch before your edits, Boone, so I had to do some merging between that branch and 2.0.x. You can see my last few commits here: https://github.com/scholarpress/scholarpress-coins/commits/2.0.x

Do we want to have the option to lock the Date and Source fields too? For those would we lock to post updated date, or original publish date? And for Source we would just lock to site title, right?

Let me know, and thanks for all your help!

Actions #26

Updated by Boone Gorges over 6 years ago

Thanks, Dan! The lock feature looks pretty nice. One suggestion: When clicking the lock checkbox, can you dynamically set the field value to the "locked" value? I experimented with this by printing each of scholarpress_coins_get_locked_fields() to its own hidden input, and grabbing it on click. This way, the disabled field will hold the actual locked value, instead of the misleading custom value. (If you go from locked to unlocked, I think it's fine to leave the locked value there - the user may want to use it as a starting point to create the custom, unlocked value.)

I don't think it makes sense to have locks for Source and Date. Locks only make sense for fields that may change. The default Source (the site title) never changes, and the Date, assuming we go with the original post date, should never change. So I don't see any value in having a locking mechanism there.

Actions #27

Updated by Stephen Klein over 6 years ago

Would you like me to start testing? If not, let me know when. Thanks.

Actions #28

Updated by Daniel Jones over 6 years ago

Good call Boone. I've added that here: https://github.com/scholarpress/scholarpress-coins/commit/56eb7693d17c767805d2e8105f373a32d1d1aa74

Right now I have so that if the user "locks" a field, it pulls in the currently saved values, not the ones entered in the relevant post field before saving: for example, it doesn't pull the value from the post's "Title" field, or a new author if that's changed, or newly added/removed categories. Do you think that works for now or should I try and pull that information in, which would likely mean AJAX requests, at least for the author and subjects fields.

And Stephen - if you wanted to test now that would be great! Still need to add in the option to have additional authors though. We're still on the 2.0.x branch, not master.

Actions #29

Updated by Stephen Klein over 6 years ago

I tested and this works great. This will be a great addition for scholarly communications. Thanks!

Actions #30

Updated by Boone Gorges over 6 years ago

Thanks for testing, Stephen.

Dan - This is looking good. I just made a few security-related comments on the most recent changeset.

I don't think it's critical to change the locked values dynamically, especially since saving a post triggers a page refresh, which will result in updated "-hidden" values.

Once the escaping fixes are in, let's put this on the Commons and get a little testing with it before we talk about a release.

Actions #31

Updated by Daniel Jones over 6 years ago

Sorry about that, Boone. Here's the most recent commit: https://github.com/scholarpress/scholarpress-coins/commit/643897249290af475940c95d65127d75d0a55657

Is there anything I need to do on my end to get in on the Commons for testing?

Actions #32

Updated by Boone Gorges over 6 years ago

  • Target version changed from 1.10 to 1.9.26

Nope, nothing you need to do :) I've updated the Commons's version of scholarpress-coins to the 2.0.x branch, and it'll be ready for use on the Commons starting with the next scheduled release (tomorrow). https://github.com/cuny-academic-commons/cac/commit/200afefa74515829060d50a7b1fff9a967cfe33f

Stephen, once the release is live, could I ask you to put it through its paces? On the site(s) where you plan to use it, make sure that the configuration options (and default value fallbacks) are working as you'd expect. Many thanks!

Actions #33

Updated by Boone Gorges over 6 years ago

  • Target version changed from 1.9.26 to 1.9.27
Actions #34

Updated by Boone Gorges over 6 years ago

  • Target version changed from 1.9.27 to 1.9.28
Actions #35

Updated by Stephen Klein over 6 years ago

Hi Boone,

A little confused by your use of Target version. What does 1.9.28 mean?

What is the expected date?

Thanks,
Stephen

Actions #36

Updated by Boone Gorges over 6 years ago

Stephen - The "Target version" field is for our internal use, so don't worry about it too much.

The new plugin is on the Commons and ready to be tested.

Actions #37

Updated by Stephen Klein over 6 years ago

Thanks, Boone. I see:

ScholarPress Version 2.0 and it already activated in JITP.
Is this correct the correct plugin and version?

Actions #38

Updated by Boone Gorges over 6 years ago

Yes, that's it.

Actions #39

Updated by Stephen Klein over 6 years ago

I think I found a bug.

This:
http://jitp.commons.gc.cuny.edu/how-i-learned-how-to-stop-worrying-and-pickle-websites-the-art-of-fermenting-the-web-with-archive-it-and-webrecorder/
keeps on being inserted under Date field.

I have deleted it a few times.
It also seems to be the only field not to have the lock feature.

Actions #40

Updated by Boone Gorges over 6 years ago

Dan, could you have a look please?

Actions #41

Updated by Daniel Jones over 6 years ago

Yes this was a stupid typo on my part! Should be fixed in 2.0.x now.

Actions #42

Updated by Stephen Klein over 6 years ago

So do we need to wait for it to be pushed to the Commons? Because I just tested and the bug is still there.

Actions #43

Updated by Boone Gorges over 6 years ago

Dan - Thanks!

Stephen - Yes, it'll wait until the next version of the Commons. The deployment process is complex, and I can't do it for the back-and-forth of bug fixing. If you'd like to test the latest changes, you can pull them into a local development environment from the GitHub repo. Thank you for testing!

Actions #44

Updated by Boone Gorges over 6 years ago

  • Target version changed from 1.9.28 to 1.9.29
Actions #45

Updated by Daniel Jones over 6 years ago

Boone - just leaving a note to see if there's anything I need to do on my end here, either getting the new version into the repository or anything else.

Actions #46

Updated by Boone Gorges over 6 years ago

Dan - Can I ask you to do the following?

1. Update the changelog in readme.txt to explain the new features
2. Make sure the plugin will load translations. I think this just means adding a Text Domain header to the plugin, and calling load_plugin_textdomain() somewhere. Take a first pass using the instructions at https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/. If you can manage it, generate a fake language pack (using Poedit or another tool) to test that it's working. Or pass it along to me, and I'll do a quick test.
3. Bump version and "tested up to" numbers in scholarpress-coins.php and readme.txt headers
4. Give me your wordpress.org username so I can add you as a committer to the plugin (sorry, I forgot what it is)
5. Nice to have! Generate a screenshot of the new interface, and add a description of it to readme.txt. See https://wordpress.org/plugins/about/readme.txt

Once all this is in place, here's how I recommend handling release:

a. Check out the wordpress.org repo: svn co https://plugins.svn.wordpress.org/scholarpress-coins ./scholarpress-coins-svn
b. Replace trunk files: rm -rf scholarpress-coins-svn/trunk/* && cp -R /path/to/git/repo/* scholarpress-coins-svn/trunk/
c. Just for safety, revert the "Stable tag" header in readme.txt to 1.3 - this will allow us to test the wordpress.org-generated zip without forcing user uploads quite yet
d. svn ci -m "Updating files for 2.0 release"
e. Create a tag: svn cp scholarpress-coins-svn/trunk scholarpress-coins-svn/tags/2.0
f. In tags/2.0/readme.txt, bump stable tag to 2.0, and then svn ci tags/2.0 -m "Create tag 2.0"
g. Wait a few minutes for wordpress.org to generate a release zip. Look under "Other versions" at https://wordpress.org/plugins/scholarpress-coins/developers/. Once it's available, download and test a fresh installation to make sure nothing explodes.
h. If everything's good, bump the stable tag up to 2.0 in trunk/readme.txt, and svn ci -m "Bump stable tag to 2.0"
i. If you created a new screenshot (step 5 above), add it to the scholarpress-coins-svn/assets/ directory with the appropriate filename. See https://developer.wordpress.org/plugins/wordpress-org/plugin-assets/

Actions #47

Updated by Stephen Klein over 6 years ago

Will the update be available in the Commons before the WP repo?

Actions #48

Updated by Boone Gorges over 6 years ago

Stephen - The 2.0 version of the plugin is already running on the Commons. The update that fixes the problem reported in https://redmine.gc.cuny.edu/issues/5490#note-39 will be part of the Commons 1.9.29 release, on October 1.

Actions #49

Updated by Boone Gorges over 6 years ago

  • Target version changed from 1.9.29 to 1.9.30
Actions #50

Updated by Daniel Jones over 6 years ago

Hey Boone - I think I've got everything ready on my end, finally. My Wordpress username is dan-jones.

Actions #51

Updated by Boone Gorges over 6 years ago

Great! Dan, I've added you as a committer to the plugin on wordpress.org. Let me know if you've got enough info to move forward.

Actions #52

Updated by Daniel Jones over 6 years ago

Awesome! Version 2.0 is live in the repository!

Actions #53

Updated by Boone Gorges over 6 years ago

  • Status changed from Assigned to Resolved

This is fantastic! Thanks so much, Dan. I'm going to open a separate ticket to track publicity.

Actions #54

Updated by Ben Miller over 6 years ago

Cross-posted from https://redmine.gc.cuny.edu/issues/3300:

Testing on http://jitpstaging.commons.gc.cuny.edu/city-of-lit-collaborative-research-in-literature-and-new-media/, I can confirm that the ScholarPress COinS translator kicks in as planned, and Zotero grabs whatever data is in the custom fields assigned by it. Thanks, Dan, for all your hard work on this plugin!

That said, unless I'm missing a way to trigger it, the plugin currently only allows for one author, with a single clear "last name" field. In the case of multiple authors, I tried a workaround of treating only the first author's last name as the requested "last name," and putting all other authors in the "first name" field, just to see what Zotero would do with it. Perhaps unsurprisingly, it treats this as a single author with a simple last name and a really complicated first name.

Don't get me wrong: it's still a vast improvement, and I'm grateful for it, and in many citation styles it'll probably even look right. But if there could be some way to make "author" a multi-valued array that Zotero could digest, that would be better still.

Actions #55

Updated by Boone Gorges over 6 years ago

Thank you, Ben!

For the sake of separating out the issues, I've opened #6435 and added you as a watcher.

Actions #56

Updated by Boone Gorges over 6 years ago

  • Related to Feature #6435: ScholarPress COinS should support multiple values for some DC fields added
Actions #57

Updated by Daniel Jones over 6 years ago

Oh wow I'm so sorry about that! I've pushed version 2.1, which should fix that problem. I've also updated it in the Commons codebase, on the 1.9.x branch.

Actions #58

Updated by Daniel Jones over 6 years ago

Sorry, ignore my last update, was related to a different ticket, which I've now updated.

Actions

Also available in: Atom PDF