Pkp-lib: 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/1828#issuecomment-297040015)]

(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 controlled_vocab_... 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?

[ajnyga]

Thanks!

After realizing that the OJS3 subject field is (or should be) the same as subjectClass field, I would vote for having two separate fields and in my opinion you can still combine these in OAI-PMH. If someone needs a more refined output there, it is easy to add a new custom oaimetadataformat.

However I want to stress the difference between a library classification and thesaurus. Both are controlled vocabularies but inherently different. The latter would be something that you would want to integrate to the keywords field but at the same time it would be a good idea to permit adding keywords from outside the thesaurus - and make a distinction between the words coming from the thesaurus and the ones that are outside the thesaurus.

This leads me to the idea of saving keyword/subject URIs/ID's - what do you think @asmecher, how would the current controlled vocabulary function in OJS3 handle this?

[Ph-We]

I would agree with @ajnyga. Roughly speaking, 'subjects' are related to 'keywords' as 'taxonomies' to 'folksonomies'. So managers might want to control both, but using different methods. (E.g. controlled vocabularies for subjects and (usually more complex) thesauri for keywords, allowing free input).

P.S. Again, AFAIK 'subjects' and 'keywords' are mostly confused in DC/GS metatags (there are no 'keywords' in DC and 'subjects' in GS).

[ajnyga]

With saving the URIs (or other identifiers) with the keyword, I was thinking something like this:

[asmecher]

Correct me if I'm wrong but I think we're all agreed on an approach -- keep both fields, and provide optional tools to curate them, particularly Subjects.

@ajnyga, on storage: would you be using a recognized third-party standard, or something home-grown? If it's a third-party standard, it might be better to have the controlled vocabulary maintained in an XML file or similar, rather than backing it in the database. Then the submissions could refer to an identifier only (e.g. URL) and have the translation fetched from the XML.

[ajnyga]

Hi,

At least in my opinion we should keep both, and provide the optional tools as well to both fields (and maybe also to Coverage etc.). I am also still voting for an easy REST API integration.

@asmecher, the vocabulary I am planning to use is this https://finto.fi/yso/en/
It is an ontology that the National Library is hoping us to use in our journals. The XML format of that ontology is around 40 megabytes, so that would probably be a problem. Also that would probably mean a lot of hacking to the code that shows the keywords in the frontend, backend and APIs.

Saving an URI together with a keyword would basically mean saving an unique identifier for that word, which I think is a good practice. But it of course doubles the data and I want to stress that I am not a library expert - maybe someone from PKP with this expertise would have a better view.

I have a backup plan to store the uri like this: Keyword [http://uri.com/path/to/keyword]
I am then parsing that with regexp in our own OAImetadataformat plugin to find out if the keyword is coming from the vocabulary. If it is, it will get a different value in Marc and will include the URI in a separate field. The problem with that solution is of course that the URI is shown in every other output. In OJS2 which used the submission_settings table to store these I had solution for this, but it does not work the controlled vocabularies model.

[Ph-We]

As to the standards, AFAIK, SKOS is the only standard recommended by W3C for maintaining vocabularies/thesauri. YSO is based on SKOS too.
Functionality to save appropriate URIs along with keywords is the least one could do.

[marcbria]

it might be better to have the controlled vocabulary maintained in an XML file or similar, rather than backing it in the database.

What if you have multiple journals with different thesaurus?
If is based in a xml file, they need to be stored in the journal's registry folder or so, isn't it?.

[asmecher]

My worry with backing a vocabulary in a database is that any 3rd-party standard is going to evolve -- loading it into the database (possibly in translations) will mean having to maintain changes there, and more often than not, deal with obsolete lists. The country/language/currency lists are a good parallel -- we've always kept those in XML and it's made maintenance way easier.

Thanks for the heads-up on SKOS -- I wasn't aware of it!

[ajnyga]

It is likely that a thesaurus or ontology will evolve. However, I do think that the URIs in thesaurus like YSO are always persistent identifiers, meaning that they will resolve somewhere - keywords/URIs are not just dropped. Also, OJS users are backing vocabularies to the database all the time, they just do not have a technical integration between a vocabulary and OJS.

The XML solution is a good one in many cases, but do you think that it will work with 40 megabyte files? One solution would be to store just the URI and then call for the label/keyword with the API. But that would result in to a lot of API calls which would could be a problem as well.

[asmecher]

@ajnyga, I don't know that standard at all, but at a glance it looks like it contains the meat of the dictionary plus a lot of tangentials (deprecated concepts, various metadata, etc). This reminds me a little of the ONIX schema we include with OMP -- in that case we used a few different tools to make an unwieldy set of XML into something usable: IIRC an XSL to strip out some unwanted elements, and some PHP code to cache specific sub-elements of the larger set.

Generally nothing involving ONIX is free of tears, but this approach allowed us to ship with the "official" ONIX code list, without causing performance problems in parsing. Caching is handled via file caches, so if the ONIX code list ever gets updated, the file caches will be automatically invalidated. And no need to sync external standards against a set managed in the database, which is always painful.

[ajnyga]

Thanks. Yes, it is a ontology, so not just about the words but more about the relationships between the words.

I have to think about the your solution with ONIX. This would require a lot of other changes as well, I mean fetching words from XML in the frontend and OAI etc. Also this would require regular updates of the local XML file.

For a quick solution I will probably just go with saving the keywords together with the URI. I can always convert these later with a custom script if another solution is available, because they include the URI part.

[asmecher]

Sounds good, @ajnyga. There may well be elements that'll be difficult to implement purely by plugin -- I haven't considered this in detail yet -- and if that's the case, changes to the core codebase may be needed. If so, I think these would be well worth integrating because this is a worthwhile feature. That said, I do think the current behavior is likely to remain as the default, because of the difficulty in identifying a good, free, broadly-applicable, widely-translated vocabulary.

[bozana]

@asmecher, the keywords migration from OJS 2.4.x should then be fixed -- they should be saved as keywords and not as subjects, right? What about the subject classification migration? -- In OJS 2.4.x we had the name and URL of subject classification, thus should this be somehow migrated too or should just the entries be migrated to subjects as they are?

[asmecher]

@bozana, there's some confusion in terminology because the OJS2 "subjects" (per the code) field is the "keywords" field (per the UI/locales). So the OJS2 to OJS3 upgrade should migrate "subjects" (per the code) to OJS3's "keywords", and "subjectClass" (per the code) to "subjects".

[bozana]

OK, that's what I meant :-) I would open a new issue just for that (migration issue) ok?

[asmecher]

Sure, please do.

[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 [e-mail]:

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
https://github.com/pkp/pkp-lib/issues/1828#issuecomment-324065965, 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: https://github.com/pkp/pkp-lib/pull/2764
ojs master: https://github.com/pkp/ojs/pull/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?