Page MenuHomePhabricator

WordPress plugin to associate tags with Wikidata IDs
Open, NormalPublic

Description

The plugin will allow WordPress editors or admins to optionally associate each tag (and optionally category?) in a blog with a specific Wikidata item.

For example, the page at:

http://pigsonthewing.org.uk/tag/opendata/

may be associated with the item:

https://www.wikidata.org/wiki/Q309901

in which case, the former page should display near its top a link to the latter. The Wikidata URI should also be included in the metadata headers for the tag page, and possibly in the headers of each blog post using that tag.

When the tag is displayed at the foot of a post, a tooltip (say, "Wikidata item: Q309901", or the Wikidata label in a language specified in the plugin's configuration settings) may be provided.

The association of a Wikidata item with the tag should take place on the dialogue page at, for example:

http://example.com/wordpress/wp-admin/term.php?taxonomy=post_tag&tag_ID=123&post_type=post

Event Timeline

Restricted Application added subscribers: Zppix, Aklapper. · View Herald TranscriptJun 22 2016, 9:40 AM
Addshore moved this task from incoming to monitoring on the Wikidata board.Jun 22 2016, 12:58 PM
Zeko added a subscriber: Zeko.Nov 14 2016, 10:55 PM
abian added a subscriber: abian.Nov 14 2016, 11:50 PM

@Zeko has agreed to complete this task as his end-of-degree project.

I encourage you to define some more (specific, preferably ambiguity-free) requirements for this plugin and to give @Zeko some advice so that he can develop the best and most useful WordPress plugin ever. ;-)

Thanks!

abian assigned this task to Zeko.Nov 14 2016, 11:51 PM

Hey @Zeko :)

Great to hear. I am happy to help and I am sure @Pigsonthewing is too. You can see my schedule at doodle.com/nightrose

Esh77 added a subscriber: Esh77.May 6 2017, 8:32 PM

I encourage you to define some more (specific, preferably ambiguity-free) requirements for this plugin

Firstly, apologies for my tardy reply; I have only just become aware of abian's comment.

Here are some suggestions; my proposed markup should please be checked by someone with a better understanding of schema.org!

My post:

http://pigsonthewing.org.uk/open-licensing-images-what-how/

is tagged (among other things) "open data", linking to:

http://pigsonthewing.org.uk/tag/open-data/

The latter page should be marked, in headers, as "sameAs", perhaps:

<meta property="dc.sameAs" content="https://www.wikidata.org/wiki/Q309901" />

and its header:

<h1 class="page-title">Tag Archives: <span>open data</span></h1>

should be changed to, say:

<h1 class="page-title">Tag Archives: <a href="https://www.wikidata.org/wiki/Q309901">open data (Q309901)</a></h1>

The link on the former page, currently marked up as:

<a href="http://pigsonthewing.org.uk/tag/open-data/" rel="tag">open data</a>

should be marked up as something like:

<span itemscope="" itemtype="http://schema.org/Thing">
    <meta itemprop="url" content="https://www.wikidata.org/wiki/Q309901">
    <a href="http://pigsonthewing.org.uk/tag/open-data/" rel="tag" itemprop="sameAs">open data</a>
</span>

The page typically at .../pwordpress/wp-admin/ should have in its left-hand navigation, a link to a "tags" page. The latter page should show all the tags used on the site, and allow the input of an optional Wikidata QID for each. If no QID is entered the markup suggested above should not be applied.

...and likewise for categories

DanBri added a subscriber: DanBri.May 16 2017, 8:55 PM

from a quick look, I wonder whether http://schema.org/about would be a good fit. In most cases you're trying to characterize the topic of the page, aren't you?

You could mark it up several ways but the basic idea would be that the 'about' property related the current page (identified by URL) to a Thing which was sameAs the Wikidata URL. Or you could just stick in the Wikidata URL directly as the value of the 'about' property.

Would this markup be in page body or page head?

Framawiki added a subscriber: Framawiki.EditedJul 20 2017, 7:27 PM
In T138371#3254217, @Pigsonthewiner ?g wrote:
<h1 class="page-title">Tag Archives: <a href="https://www.wikidata.org/wiki/Q309901">open data (Q309901)</a></h1>

I think that site owners must be able to hide Wikidata to readers, I say that they can hide Q309901 like codes. Perhaps using <a href="https://www.wikidata.org/wiki/Q309901 alt="Q309901">open data</a>, a link with a alt parameter, is better

In T138371#3254217, @Pigsonthewiner ?g wrote:
<h1 class="page-title">Tag Archives: <a href="https://www.wikidata.org/wiki/Q309901">open data (Q309901)</a></h1>

I think that site owners must be able to hide Wikidata to readers, I say that they can hide Q309901 like codes. Perhaps using <a href="https://www.wikidata.org/wiki/Q309901 alt="Q309901">open data</a>, a link with a alt parameter, is better

alt is not an allowed attribute for a. You can use title (<a href="https://www.wikidata.org/wiki/Q309901" title="Q309901">open data</a>), which makes it valid html.

Zeko added a comment.Oct 16 2017, 11:33 AM

Hello and sorry for the late reply.

Been working on this lately and I have some questions and some suggestions.
As said by @DanBri I understand this as a topic characterizing of the page (or tag), and an linker to the associated wikidata item and before discussing how to make this (I like the ideas shown here but I think we should define specifically how to implement that) we should talk about how to associate tags or categories to wikidata items.

As @Pigsonthewing said we could add a dialog to make the user make the assoc in a dialog page related to the tag or category (if I understood that correctly) but (I repeat, if I understood it correctly) it could be really tedious for the user to make them one by one. So in a first approach I find logical to make that association, so that the user can handle all of them from one place: in the plugin setup page. But there may be some problems in how to make that association.

  1. We could let the user just add the wiki item id into a textfield and "poof": magic, done. Later we just have to add the assoc to the meta of the page and done. (After we discuss exactly and specifically how to do it)
  2. We could add a semi-automatic way to make the associations. I mean, all tags are a specific and relevant "keyword" or "keywords" and using the wikidata api we can get a list of wikidata items whose title are related to that "keyword" (or the tag name if you like it better) so we can make the user just disambiguate the term. For example: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=car&language=en would get us a json with some simple but relevant info about wikidata items related to the search of the term "car" among which the user could decide for the most suitable for his tag.
  3. If we do this, I am not sure we need a dialog page, we could make that with ajax or even just javascript, just showing a little pop-up dialog next to the "manual field" so the user selects from there to disambiguate the assoc.
  4. Anyway I would let both options, so if the automatic can't find a proper item for the user (very long tag name, or searchs with very large disambiguation lists) he can just go to wikidata, look for the id he wants to assoc to, and paste it in the textfield.

In addition to this, we could make this also for posts, we though about a metabox in the post editing area in which we could add new associations, and even more, add formatted references (ie: harvard or ieee format) to the post text but that will be up to you =)

waiting for your opinion =) Thank you!

Pigsonthewing added a comment.EditedOct 16 2017, 1:14 PM

waiting for your opinion

Thank you for this Zeko. All the suggestions you make seem to me to be good ones. I especially like your proposal to allow multiple forms of entry. Ajax would also seem to be fine.

I am happy to test a prototype, when you are ready.

Zeko added a comment.Oct 17 2017, 11:13 AM

I am happy to test a prototype, when you are ready.

Sure =) asap

Quick but non trivial question here: I am considering using external libraries for some things, as I intend to release the plugin under a GPL, can somebody tell me what kind of problems can we have if I use libraries as bootstrap??

Here are fontawesome and bootstrap licenses:

apparently there is no problem in using them (even for commercial purposes) but I am not sure if it could get in conflict with wikimedia policies.

thank you!

Hi! @Pigsonthewing asked for my feedback on this as I'm a WordPress developer, and I'm happy to help.

The proposal sounds good, and it'll be nice to get more metadata like this onto WordPress sites. I have one piece where I'd suggest the change would not make sense. The proposed change to make page titles use something like this:

<h1 class="page-title">Tag Archives: <a href="https://www.wikidata.org/wiki/Q309901">open data (Q309901)</a></h1>

My feeling is that many site owners would find that to be undesirable - taking people away from their site to a page that might not necessarily add more to their experience. The average user is unlikely to care much for that wikidata page :)

Otherwise, the approach sounds pretty good. I'd recommend the following;

  1. Include a field on the term edit screen (e.g. Posts > Tags > [Tag] > Edit). There is a term meta API for this in WordPress (see add_term_meta())
  2. Auto-add meta data on post save. To automate things a little, I'd suggest the following process happen whenever a post is saved;
    • Each term attached to the post is retrieved and queried against the wikidata API
    • If an exact match is found, the term meta for that term should be updated to add that term ID (if one isn't already present)
    • This process could be problematic for performance, so I'd suggest the first step happen in a cron job to avoid making post saves horrendously slow
    • The response from the wikidata API should also be cached for around 24 hours, to avoid unnecessary repetition.
  3. It should be possible to enable this for both categories and tags
  4. It should be possible for plugin and theme developers to enable this for their custom taxonomies. This can be done by passing an array of supported taxonomies through a custom apply_filters() hook.
  5. I don't think this plugin needs it's own settings page - the term meta API should provide all the UI we need, and anything more would add unnecessary complexity.

Please do code in the open and I'll be happy to provide some peer review as the project moves along.

Thanks!

Thank you, @Philipjohn21

If an exact match is found

The problem with that is the ambiguity which linking to is intended to overcome. For instance, does "Paris" refer to "Paris, France", "Paris, Texas", "Paris of Pram", or "Paris Hilton"?* We need some mechanism which prompts the user to select the appropriate match.

Philipjohn21 removed Zeko as the assignee of this task.Oct 18 2017, 6:19 AM

Ah yes I see what you mean :)

Scrap that idea then... I think the field on the term edit page with an ajax search is a good idea.

I'm not sure we can avoid the manual effort that requires of the user without interrupting the save post flow, which could be frustrating.

Zeko added a comment.Oct 18 2017, 7:51 AM

Include a field on the term edit screen (e.g. Posts > Tags > [Tag] > Edit). There is a term meta API for this in WordPress (see add_term_meta())

This is really nice to know and will save a lot of work =)

My feeling is that many site owners would find that to be undesirable - taking people away from their site to a page that might not necessarily add more to their experience. The average user is unlikely to care much for that wikidata page :)

That is something that worried me off, that could be a little intrussive

I'm not sure we can avoid the manual effort that requires of the user without interrupting the save post flow, which could be frustrating.

But what if the user has already set the associations? He can just focus on his post and forget them, that is the point of the setup page, however we could add some kind of setup during the edition of posts for new tags. Anyway I don't know how frequent is to add new tags ior how many of them can be added in a row.

The code up to this time is at https://github.com/zeko3991/Wikidata-references that is NOT the official repository. Later on I will upload to an official repository of the University of Zaragoza.

Don't freak out if you see strange things in the code, I'm quite new at wordpress developing and still have to try trivial things to see how it works =) everything will be clean at the end.

Also I'd want to insist about the license topic I asked before.

Thank you!

Zeko claimed this task.Oct 18 2017, 7:52 AM
abian added a comment.Oct 18 2017, 8:50 PM

Quick but non trivial question here: I am considering using external libraries for some things, as I intend to release the plugin under a GPL, can somebody tell me what kind of problems can we have if I use libraries as bootstrap??

"MIT licensed software can be integrated into GPL software, but not the other way around". If you want to publish the plugin under a GPL, I think there will be no problem.

The MIT and the GPL are free software licenses and, therefore, compatible with the Wikimedia movement.

thiemowmde triaged this task as Normal priority.Oct 27 2017, 12:12 PM
thiemowmde added a project: patch-welcome.
Zeko added a comment.Nov 7 2017, 10:05 AM

Hello! Here again to update the progress:

First, I added some "ordinary" metadata options to be added at html head, just if the user wants them to, for the moment they're just a few, but I can add more as you find them relevant.
I also included the option to add that metadata to wp posts.

(metadata at hmtl head)

(and metadata at posts -at wp_postmeta column in wp database-)

Of course, if option is not activated, plugin will delete all data it added.

Now, with our wikidata ids =)

Added two options, first one to change tag archive title at tag pages for a link to wikidata term, and other to add the wikidata link to term metadata.

First, the link: that will only be active if user wants to and if the tag has an associated wikidata id

Second, adding wikidata link to tag metadata: (at wp_termmeta in wp database)

I will be happy to hear your thoughts and any opinion or suggestion =D

Sadly, Zeko has not replied to my mails, since before Christmas. While hoping he is well, we must assume that he has abandoned this project. Can anyone else pick it up and complete it? Maybe at the hackathon?

Is https://github.com/zeko3991/Wikidata-references the most up to date code for this? Or was it moved to a WordPress-hosted Subversion repository?

Is https://github.com/zeko3991/Wikidata-references the most up to date code for this? Or was it moved to a WordPress-hosted Subversion repository?

AFAICT, the former.

There is also a similar, but independent, project described at:

https://blogs.pjjk.net/phil/wikidata-linked-data-wordpress-indexes/

jgleeson removed a subscriber: jgleeson.
Platonides added a subscriber: Platonides.EditedMay 30 2018, 11:23 PM

Hello

Thanks @Zeko for his work tackling this development. We have quickly tested the current plugin and it seems there is still ample room for improvement. In particular, the entire lists of tags and categories disappear from the UI each time you access, and the search for items in Wikidata does not seem to work. :/

Cheers