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) (pkp/pkp-lib#1807 b) locale placeholder for keyword form input fields #2499 and pkp/pkp-lib#1807 b) a fix for locale placeholder for keyword form inp… #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. (pkp/pkp-lib#1828 consider keywords for display, DC and GoogleScholar indexing ojs#1518)
4. There is no option to display keywords on the article page. (pkp/pkp-lib#1828 consider keywords for display, DC and GoogleScholar indexing ojs#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)): #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 б: #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.

[asmecher]

@bozana, are you still working on this one?

[bozana]

@asmecher, I never did -- I just fixed the migration issue.
From the original post: 1) is solved, 2) I am not sure we can do anything about, 3) I could do, 4) I believe @NateWr wanted to work with the display.
The further requirements like use of dictionaries etc I would defer and put in a new issue.
What do you think?

[asmecher]

@NateWr, does @bozana's suggestion work for you? Would you like to put some effort into keyword display for 3.1?

[bozana]

@NateWr, I can also do 4) if you would tell me where and how to display them best :-)

[NateWr]

@bozana That'd be great. I'd think they'd be best just below or above the abstract. You should be able to do it with the following HTML, requiring no additional styling.

<div class="item abstract">
  <p><strong>Keywords:</strong> <a href="#">first</a>, <a href="#">second</a>, <a href="#">third</a></p>
</div>

[Ph-We]

I would vote either for the 'above the abstract' option, or for putting keywords somewhere between the galley and 'published' blocks.
The abstract may be too long, and keywords may usually describe the article 'in a few words'. So it would be better for them to be visible at first glance.

[marcbria]

I arrive late to this thread... so sorry in advance if I'm only adding noise to the discussion.

@NateWr I have doubts here:

• Is "strong" the right tag for the label? https://www.w3schools.com/tags/tag_strong.asp
• Should be better (for theming) build a ul-li list for each keyword?
• Why not adding "rel=tag"?

I found this discussion... but unfortunately it's really old:
https://stackoverflow.com/questions/12866008/html5-semantic-markup-for-blog-post-tags-and-categories

Did you search for "best practices" (or "patterns" or "components" or whatever they like to call them) to see how others are dealing with this. It's very close to a blog's tag so from an html perspective, we can adopt the most extended solution, don't you think?

[Vitaliy-1]

Google is not indexing keywords at all. So they are needed mostly for authors for better navigation inside the journal. 2017-08-22 18:38 GMT+03:00 Marc Bria <[email protected]>:

…

I arrive late to this thread... so sorry in advance if I'm only adding noise to the discussion. @NateWr <https://github.com/natewr> I have doubts here: - Is "strong" the right tag for the label? https://www.w3schools.com/ tags/tag_strong.asp - Should be better (for theming) build a ul-li list for each keyword? - Why not adding "rel=tag"? Did you search for "best practices" (or "patterns" or "components" or whatever they like to call them) to see how others are dealing with this. It's very close to a blog's tag so from an html perspective, we can adopt the most extended solution, don't you think? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1828 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATtU8_zXWq2iYQF0z5qAlMpGFiGEAfjWks5savYLgaJpZM4KALVi> .

[NateWr]

Is "strong" the right tag for the label? https://www.w3schools.com/tags/tag_strong.asp

I suppose it probably would be good to follow the .item, .label, .value pattern we've already established:

<div class="item doi">
	<span class="label">
		Keywords:
	</span>
	<span class="value">
		first, second, third
	</span>
</div>

But we'll need to update the CSS for the default theme and defaultManuscript to place them inline (like the DOIs). (@bozana, you can give me a nod when you want me to do that.)

Should be better (for theming) build a ul-li list for each keyword?

The keyword data should be available for themers to build their own HTML output.

Why not adding "rel=tag"?

I jumped the gun above. We won't actually have a page for each keyword to view articles in that keyword in 3.1. So there won't be any links there.

It's worth considering when we do have keyword-based browsing, but we'll need to consider other grouping strategies (sections, subjects) before settling on a rel for any particular browsing approach.

[NateWr]

Did you search for "best practices" (or "patterns" or "components" or whatever they like to call them) to see how others are dealing with this

I did look at eLife, PlosOne and UbiquityPress. Only Ubiquity was even displaying keywords, so they don't seem to be a high priority, and Ubiquity is probably just displaying them because they were part of OJS 2. Still, they're doing <label>: <list of keywords>.

[Ph-We]

@Vitaliy-1

Google is not indexing keywords at all. So they are needed mostly for
authors for better navigation inside the journal.

I think Google indexes keywords, but they do not use them for ranking pages indexed. Google Scholar should index both Dublin Core and HighWire (GS) tags. At least, Arlitsch & OBrien recommend adding the appropriate metatags, and they did a lot of research in this field :)
https://books.google.ru/books/about/Improving_the_Visibility_and_Use_of_Digi.html?id=KxKSAwAAQBAJ&redir_esc=y

UPD: I double checked the document, Google sent to us:
'ADDING MACHINE READABLE BIBLIOGRAPHIC METADATA TO SCHOLARLY ARTICLES'
It contains recommendations to add keywords as metadata:

[marcbria]

• About "strong", I'm happy with @NateWr new proposal (without "strong" ;-) )

• About html structure based on ul-li, it's for making theming easier... and progressively move to something more standard (BAM?).

• About rel="tag", I just forget out keywords aren't linked to a key-page so actually didn't make much sense microformats (ToDo: link keywords :-) )

BTW, taking a look to Plos and UbiquityPress (this last one is tricky because as you said is an OJS, so is like looking ourselves) is good but, apart of our small academic universe, we also need to keep an eye on cutting edge cms (like wordpress, drupal, joomla...) to see what are becoming a new standards.

@NateWr I know you are very familiar with wordpress, so if you think is not the right moment to change our ojs' list-items-pattern I'm ok with your decision.

[bozana]

PR for 3) and 4) from the original issue:
pkp-lib master: #2764
ojs master: pkp/ojs#1518

[bozana]

@NateWr, I displayed the keywords in front of abstract and in the same way and size as DOIs. If I should change that, just tell me... Could you review the PR above? It also solves the other issue mentioned here: to consider keywords for DC and GoogleScholar indexing.

[bozana]

I think I can close this issue -- if something from the discussion should be addressed later, maybe to open a new issue?