Issues with input and display of keywords

[Ph-We]

Hi!

Here are the issues found for keywords functionality:

1. The keyword fields are not labeled according to their locales (in multilingual journals) (#2499 and #2510)
2. Creation of a new keyword is triggered by ENTER or the comma sign (“,”). But the latter is not bound to the same key in different keyboard layouts. For example, in the Russian layout there is a “б” character instead of the comma, so every time I enter “б”, a new keyword is created.
3. Keywords entered are not included as metadata (DC/GS metatags) on article pages. (https://github.com/pkp/ojs/pull/1518)
4. There is no option to display keywords on the article page. (https://github.com/pkp/ojs/pull/1518)

http://forum.pkp.sfu.ca/t/ojs3-keywords-are-not-displaying-anywhere/20125/3

[NateWr]

I've updated the title and description of this issue to reflect that the keywords as metadata is handled in a separate issue.

[bozana]

The 1. point is also in this issue (s. b)): https://github.com/pkp/pkp-lib/issues/1807. The second I do not know what to do with :-\ The third, @NateWr, any ideas on that? Else, maybe to deffer this to 3.0.2?

[Ph-We]

Hi @bozana,

As to the second, I could clarify that. Now entering a new keyword is 'physically' bound to certain keys. Whereas theoretically this should be bound to certain characters (",", ";" etc) wherever they may be in the keyboard layout. So if this is a problem, I would propose to make 'ENTER' the only key that triggers a new keyword. Is it OK?

[asmecher]

@Ph-We, with the 3rd-party control (Tag-It) that we're using, changing key-bindings unfortunately isn't an option. It might be possible to find a more flexible control, but it's potentially a lot of work. One option might be to contribute back to the upstream project to add support for keybinding flexibility, but long story short, it's not an easy change.

[novikoffav]

Hi, In my OJS 3.0.1 also no keywords on article page. How to fix it?

[asmecher]

@novikoffav, this issue is scheduled for OJS 3.0.2, so keywords won't be displayed on article pages until that release. If you want, watch this issue and when it gets some developer attention you can be notified (and possibly apply the changes to your own install).

[Ph-We]

Hi @asmecher, How could I track the issue with keywords not being included into DC/GS metadata? It was removed from here (see 3) into another one, then renamed and so still has not been solved. Thank you!

[NateWr]

@Ph-We On the right sidebar of the issue (#1815) you'll see a Subscribe button you can use to get notifications of any changes to that issue.

[Ph-We]

Hi @NateWr, I know, thanks. But that issue is not labeled as OJS related. And it is not related to keywords proper.

[asmecher]

@Ph-We, regarding:

How could I track the issue with keywords not being included into DC/GS metadata? It was removed from here (see 3) into another one, then renamed and so still has not been solved. Thank you!

Where do you expect to see them in the OAI interface (i.e. what DC element)?

[Ph-We]

Hi @asmecher,

I am talking about DC/GS metadata in OJS 3 (article pages). In OJS 2 those looked like this:

meta name="citation_keywords" xml:lang="en" content="democracy"/
meta name="citation_keywords" xml:lang="en" content="politics"/

So it was not a DC element. It was HighWire, adopted by Google Scholar. And that is correct if we are talking about indexing in GS.

[bozana]

If I understand it correctly, there should then be added something like this, but for keywords, or this replaced with keywords: https://github.com/pkp/ojs/blob/master/plugins/generic/googleScholar/GoogleScholarPlugin.inc.php#L102-L106 -- the keywords are apparently not get in the same way, with getSubject, as in 2.4.x, but with getKeywords in SubmissionKeywordDAO, right @asmecher?

[Ph-We]

UPD: Actually, in OJS 2 keywords were written both as HighWire (GS) and Dublin Core. The latter looked like this:

meta name="DC.Subject" xml:lang="ru" content="democracy"/
meta name="DC.Subject" xml:lang="ru" content="politics"/

And that was correct too.

[asmecher]

Hmm, it looks like we have options for both Keywords and Subjects in OJS 3, and the Subjects field behaves as you expect WRT indexing, but Keywords does not. I don't recall any reasoning for having both of these -- I suppose it's possible that we merged OMP and OJS 2.x metadata concerns and ended up with redundant fields?

[Ph-We]

Hi @asmecher, It is recommended to add DC to HighWire, since the latter does not describe some resources (including articles) fully. DC is also good for other indexers. There is no redundancy here (if I get what you mean).

[bozana]

@asmecher, maybe current subject field/metadata means the earlier subject classification filed/metadata? And the current keywords field/metadata means the earlier subject :-)

[Ph-We]

@bozana, @asmecher,

DC.Subject is just the same as citation_keywords. I mean, DC.Subject is the field for keywords in Dublin Core (DC). See here: http://purl.org/dc/elements/1.1/subject

While citation_keywords is a HighWire (GS) field. And it is absolutely OK, if they go together. That is the way they should be :)

[Vitaliy-1]

Hi @asmecher , As for cyrillic letter б: https://github.com/pkp/pkp-lib/issues/2299 Where widget's code is situated inside ojs installation directory? I can take a look at it.

[asmecher]

@Vitaliy-1, it's in lib/pkp/js/lib/jquery/plugins/jquery.tag-it.js. Note that it might be best to switch to another widget rather than modifying this one, if another suitable candidate is available without the same flaw.

[Ph-We]

Hi @asmecher, Some people propose using select2 instead of tag-it: https://github.com/ixti/redmine_tags/issues/87 The "б" letter is quite frequent in many Slavic languages, so we would be quite happy if some workaround might be found :)

[Ph-We]

As I've suspected, other languages are affected too: https://github.com/aehlke/tag-it/issues/349

[NateWr]

I've heard Select2 mentioned a lot. I know that neither it nor any other of these multi-select components are accessible. But I don't think that's a problem we can realistically solve ourselves.

[ajnyga]

Hi, can't confirm that letters ö, ä, å would be affected as it is suggested in the issue above. I also tested all other similar letters I could think of, but still no problem. Both in Chrome and in Safari.

[Ph-We]

Hebrew was reported to be affected: https://github.com/aehlke/tag-it/issues/22 I suspect Chinese, Japanese and any other languages with many symbols in their alphabets might be affected too.

[rkhalikov]

Is there any progress on this issue? We tried to fill both the subject and keywords fields (OJS 3.0.2). Alas, no keywords are displayed either in the meta tags or on the article page... :(

[bozana]

@rkhalikov, no unfortunately not yes, as far as I can see. Stay tuned... :-) @asmecher, I will then change the DC.Subject and citation_keywords in the metadata to list keywords instead of subjects, OK? @NateWr, do we have any plan on presenting/display of subject fields on the article page? All other issues I will leave for now...

[ajnyga]

"I will then change the DC.Subject and citation_keywords in the metadata to list keywords instead of subjects, OK?"

So what happens to all the content in the subject field? I mean, won't it show anymore in for example OAI? What about all the old content the journals have in that field?

[bozana]

@ajnyga, the OAI or anything else will not change -- just the DC and google scholar meta tags in the HTML header -- the subject field content was not there however (neither in OJS 2.4.x nor in OJS 3.x) -- it was wrongly accessed in OJS 3.x, s. https://github.com/pkp/ojs/blob/master/plugins/generic/dublinCoreMeta/DublinCoreMetaPlugin.inc.php#L122-L126.

[ajnyga]

Ok, thanks. But do you really mean that DC.Subject will use the content entered to the Keywords field in OJS metadata? And if so, what will happen to the Subject field in the OJS metadata?

[bozana]

@ajnyga, hmmm... I thought that the current subject field is something like subject classification in OJS 2.4.x, but it seams that the keyword fields from OJS 2.4.x are called "subject" and also migrated as such to 3.x i.e. to the subject fields :-( Thus, now I do not understand the meaning of the keyword field in OJS 3.x :-( I will then only change it so that the access to the subjects fields for those meta tags is correct, and @asmecher could maybe tell what is then the meaning i.e. how the keywords field should be used. And what about the subject classifications from OJS 2.4.x? I also assume then that the subject fields are wished to be displayed on the article page... Thanks a lot for double checking @ajnyga!!! :-)))

[ajnyga]

Hi @bozana, that is exactly the same question I asked a couple of weeks ago: http://forum.pkp.sfu.ca/t/display-of-keywords-in-ojs-3-0-2-0/28742/12 :)

What ever the future of these two fields is, some decisions are really needed because probably the current OJS users could be using the fields the wrong way and will have to migrate the already saved data from one field to another.

[rkhalikov]

Absence of keywords is a huge issue of OJS in the light of Scopus, etc. Very sad that PKP ignores it for so long :(

[ajnyga]

@rkhalikov keywords are not absent in OJS. OJS has had the Subject field a long time which is basically the equivalent of Keywords in Dublin Core. It is only the presentation of these words in the article page that has problems at the moment. And the second question is whether there should be two separate fields here (keywords/subject) and if so, what is the difference.

[bozana]

@rkhalikov, and this is only in OJS 3.x, that is pretty new, so not such a big problem and we are not ignoring it -- so much other things to do -- thus not that sad after all...

[Ph-We]

@rkhalikov, I do not think that might be relevant to Scopus requirements, since AFAIK they do not require keywords to be displayed on the article page. They only require them to be transferred as part of metadata.

[rkhalikov]

@Ph-We, do you realize that in OJS 3.0.2 neither subjects nor keywords are included as metadata (DC/GS metatags)?

[bozana]

@rkhalikov, how does the integration of OJS articles into the Scopus work?

[Ph-We]

@rkhalikov, Yes, I do realize, since I created this issue :D But still I believe, it has nothing to do with Scopus requirements. Since Scopus would not get your metadata from DC/GS metatags. AFAIK, they would get them from e.g. DOAJ or some XML format you would be able to provide. Please, correct me, if I am wrong.

[rkhalikov]

@bozana, the integration as such is not a question. The point is that we are new users and we are deploying OJS for several journals with a focus on Scopus and so on. We put comprehensive info into OJS itself, including keywords, etc. But we get pared down info at the output. That is the question...

[NateWr]

do we have any plan on presenting/display of subject fields on the article page? All other issues I will leave for now..

@bozana, I think there was an issue floating around specifically about visual display of this metadata, but I can't seem to find it. My thinking is that this will be implemented alongside browsing by subject/keyword, and that this is something we plan to do for the next theme which has been designed but needs some feature extensions like this.

[asmecher]

First,a survey of keyword fields in past releases:

• In OMP 1.2.0:
  • Keywords are stored using controlled vocabulary tools with symbolic='submissionKeyword'
  • Subjects are stored using controlled vocabulary tools with symbolic='submissionSubject'
  • Subjects seem to be provided via DC as DC.Subject (though I'm not sure this is working)
  • Keywords are provided to Google Scholar via citation_keywords
• In OJS 2.4.x:
  • The "Keyword(s)" field in the UI is called subjects in the code (getSubject/setSubject). It's stored in article_settings with setting_name='subject'.
  • [Edit: There's also "Subject Classification" metadata available.]
• In OJS 3.0.2:
  • Keywords are stored using controlled vocabulary tools with symbolic='submissionKeyword' (as OMP)
  • Subjects are stored using controlled vocabulary tools with symbolic='submissionSubject' (as OMP)
  • Keywords are provided to DOAJ, MEDRA, and article_details.tpl (where it's promised but not yet displayed)
  • Subjects seem not to be used much (beyond e.g. the XML import/export plugin)

The upgrade process from OJS 2.x to 3.x takes OJS "Keywords" (subjects in the code) and moves it into the OMP/OJS3.x Subjects field.

[asmecher]

Conclusions from the above:

• OMP and OJS 3.x have separate Subjects and Keywords fields. The distinction isn't clear, and in particular the Subjects field isn't really used anywhere.
• OJS 2.x didn't have this distinction [edit: OJS2 did have subjectClass]. Neither, for example, does Dublin Core.
• The migration process from OJS 2.x to 3.x moves content from the Keywords field into the Subjects field.

Proposal: Unless we can justify both fields, we should merge the data from Keywords and Subjects into a single field (suggest calling it Keywords, but either name would be serviceable IMO). [edit: see this comment]

(https://github.com/pkp/pkp-lib/issues/1815 will need to be updated per changes here.)

[ajnyga]

Hi,

Thank you @asmecher ! Couple of comments.

• If you go with one field, using "Keywords" is a good idea. The people who know about DC are capable of figuring out it is the Subject field in the metadata and people who are not, understand the concept "Keyword" way better when they see it in the UI.

• The case for having two fields: if we would have two separate fields, we could have one field for controlled vocabularies (thesaurus) and the other one for more specialized keyword for which you do not tend to have vocabularies for. This is pretty much the only scenario I can think of that would justify two fields.

• That said, it would be nice to have an added feature to the keywords field, that is saving a vocabulary specific URI together with the keyword. In controlled vocabularies the URI is actually more important than the word itself, because it is the unique id of the word (the same word could be available in many languages and the URI is the key to fetch all the language versions).

[NateWr]

I'm not concerned about which approach we take, but just to let you know that one of our plans for the frontend was to eventually allow browsing by Subject/Keyword. This would be like a "Topics" list that could be useful for continuous publishing models, as seen in the sidebar of this sample theme design:

We'd only need one of the fields and I imagine it would be a controlled-vocabulary field.

[bozana]

I am a little bit concern by having only one field -- it would be difficult to have both in one filed, controlled vocabulary and free keywords, right? I heard a lot of times that the people would like to use DDC or other kind of classification, even filter by it and provide OAI sets based on it. On the other side, I am not sure how many journals really use such classifications, for example how well the OJS 2.4.x filed Subject Classification was used... Thus, I believe we could combine them for now and think of a solution for other cases i.e. thesaurus/classification uses... ?

[NateWr]

One of the goals of using a "topic" browse ability on the frontend is to encourage people to pay more attention to this kind of metadata. By putting it on their site, we'd hope to encourage people to be more disciplined in their use of it.

But whether or not the Subject/Keywords metadata is the right data to use I'm not sure.

[ajnyga]

Hi @bozana. It was actually exactly because I am planning to integrate a Finnish thesaurus to OJS that I started to ask about this feature.

Here is a roundup of the different fields in OJS2 and OJS3. I realized, that what got me confused is the fact that the the Keyword field in OJS2 was named subject in the database. I actually had forgot that the label was indeed "Keywords". Also, what makes this even bit more complicated is that in OAI-PMH the value of DC:Subject is actually taken from three different fields.

It seems likely, that the OJS2 subject field (I am talking with the id names here) in OJS3 is the keywords field and the Subject classification field is in OJS3 the subject field. Right?

If the OJS3 Subjects field is the same as Subject classification, then there could be benefits in keeping a distinction between a library classification (like DCC or Library of Congress Subject Classification) and a controlled vocabularies (like Library of Congress Subject Headings).

Just to be clear: when I talk about controlled vocabularies, I am talking about vocabularies that you call via an API. Like this one: http://api.finto.fi/

What OJS would also need is an easy way to integrate REST API vocabularies to the keyword/subject field. This would not be that difficult. This can be done with a plugin, but it involves ugly preg_replace hacking.

I do not know if this is too far fetched or how exactly it would work but how about:

• Have the current two fields and clear instructions that the subjects field are for library subject classifications
• Have an option to attach an REST API vocabulary to both fields
• If the selected word is from the vocabulary, save both the keyword and URI
• if the selected word is not from the vocabulary, just save just the word
• have separate functions to list these fields separately in the UI if needed
• combine the fields in DC like in OJS2
• When called for either of these fields, you could list:
  • all words regardless of if they are from a controlled vocabulary (Nate's user case)
  • just the words with no uri (the "free" words) This applies especially to the keywords field
  • keywords based on specific URI domain; return both the word and the URI (Bozana's user case, and mine too)

Edit: this is the final version of the message :)

[bozana]

It seems likely, that the OJS2 subject field (I am talking with the id names here) in OJS3 is the keywords field and the Subject classification field is in OJS3 the subject field. Right?

@ajnyga, I first thought so, but the OJS2 subject field was migrated to the OJS3 subject field, and OJS2 subjects classification was not migrated at all -- it stayed as it was in the table submission_settings (and not migrated to the OJS3 controlledvocab... tables).

[ajnyga]

Hi @bozana, please see my updated message above. It had some inconsistencies earlier while I was figuring this out.

If that is the case, then there has been a clear mistake IMHO. The only scenario that makes sense is that subjectClass => Subjects and subject => keywords.

[asmecher]

Thanks for the details, all --

Since we do have toggles on metadata fields in OJS 3.x, it would be possible for us to maintain both "Keywords" and "Subjects" fields and leave the importance of the distinction up to the manager. We had a brief email discussion about distinction as well:

Brian wrote:

Your distinction between subjects (more controlled) and keywords (free range) is correct. The subjects concept is near and dear to librarians but it then requires identifying one or more subject classification schemes and even indicating which one(s) you are using. Then there are all of the attendant issues of whether you pay attention to any of this when you actually index and display content. At this point I would agree it makes sense to just maintain an uncontrolled keywords field.

Alec wrote:

The difference (to this non-LISer) seems to be that Subjects are more controlled and specified, where Keywords are freer.

On controlled vocabularies (which I agree are an important subject): both of the OJS3 fields are backed by the controlled vocabulary tools for storage, so limiting entries to a classification would be a relatively minor job. We could do this as we like, i.e. constraining the Keywords field, or the Subject field. The biggest reason we haven't done this yet is because we would need a good subject classification standard that's freely licensed and translated broadly. Suggestions welcome. Because a "universally useful" subject classification is a unicorn, I do think we should make a constrained controlled vocabulary optional, not default behavior.

So I see two options:

1. Continue to maintain both fields. We probably ought to migrate subjectClass from OJS2 to Subjects as @ajnyga suggests. Eventually add tools to constrain/maintain e.g. the Subjects vocabulary (optionally).
2. Alternately, merge both into one field. Eventually add tools to constrain/maintain e.g. the Keywords vocabulary (optionally).

I'd forgotten about the OJS 2.x subjectClass field in my review -- now that I'm reminded, it seems like potentially a good reason to maintain the distinction.

On the DC interface:

what makes this even bit more complicated is that in OAI-PMH the value of DC:Subject is actually taken from three different fields

This is historical from very old releases of OJS2. I simplified this when I rewrote the OAI interface for OJS3. (We could probably still stand to review this while we're monkeying with that aspect of the code.)

So, are the two options outlined above suitable? Are there others we should consider?