@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!

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

In T138371#2794282, @abian wrote:

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

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?

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#3457583, @Framawiki wrote:

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.

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!

In T138371#3687027, @Zeko wrote:

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.

In T138371#3687264, @Pigsonthewing wrote:

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:

• https://v4-alpha.getbootstrap.com/about/license/
• http://fontawesome.io/license/

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 [[ https://developer.wordpress.org/reference/functions/apply_filters/ | 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.

• You can see what I mean if you type "Paris" into the search box at https://www.wikidata.org/wiki/Wikidata:Main_Page - then click the "more" link a couple of times

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!

In T138371#3689998, @Zeko wrote:

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.

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?

In T138371#4058199, @Samwilson wrote:

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/

See https://wordpress.org/plugins/references-for-wikidata/ and https://plugins.trac.wordpress.org/browser/references-for-wikidata/, under the GNU GPL v3 license. This should be tested... and used! :-)

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

@Pigsonthewing: Hi! This task has been assigned to you a while ago. Could you maybe share an update? Do you still plan to work on this task, or do you need any help?

If this task has been resolved in the meantime: Please update the task status (via Add Action... → Change Status in the dropdown menu).
If this task is not resolved and only if you do not plan to work on this task anymore: Please consider removing yourself as assignee (via Add Action... → Assign / Claim in the dropdown menu): That would allow others to work on this (in theory), as others won't think that someone is already working on this. Thanks! :)

Would it be possible to add REST API support ? It would be great to have a separate JSON field when using the GET /wp/v2/posts/<id> endpoint for example.

And making it translatable would be great too