Fields to link our Crops to the same Crop in other databases

[roryaronson]

How about we start out with these four other databases: Wikipedia, Wikidata, Growstuff, and EOL? So when a member is editing a Crop page, there are four fields for "Link to this crop on Wikipedia _______", etc.

Then on the crop page, we could display it like: "Also see Cherry Tomatoes on Wikipedia, Wikidata, Growstuff, EOL"

Related to #641

[Em-AK]

Do we really need to store a copy of all these links in openfarm database ? If a crop is associated somehow with its Wikidata ID, then the links of the same crop on other databases could be stored and fetched directly on/from wikidata.

[roryaronson]

Good point @Em-AK!

What do you think is better: A) Many sites all linking to each other (a web), or B) Many sites linking to one 'canonical' site (wikidata), which links to all the other sites

Option A seems more resilient and Internetty, but would have a lot of data duplication. Option B seems more organized and collaborative on a larger scale, but then makes all of the smaller sites reliant on wikidata for the linking to other places.

Personally, I find Wikidata pretty difficult to navigate/use/edit. So I would enjoy the data being on OpenFarm too.

[Em-AK]

As an OpenFarm user

when I visit a crop page

• if the link to wikipedia / grow stuff / EOL exist it is displayed and I can click on it
• if one of the link doesn't exist, then there is a form field so that I can add it

Behind the scene

when a new link (wikipedia / grow stuff / EOL) is added by a user, then the link is added to Wikidata via its API.

For this to happen the starting point is to link each OpenFarm crop to wikidata. I just wonder what could be the best strategy to do this.

@maxlath can you explain us what is your strategy for that on https://github.com/inventaire/inventaire ?

[maxlath]

on inventaire.io, you have two way to access wikidata data:

• by a text search, which uses the wikidata search api to find entities. For instance, you can search for Jules Verne, which will point you to https://inventaire.io/entity/wd:Q33977/Jules_Verne among other results: notice the Q33977 in the url, it's a direct reference to the wikidata entity, from which everything else is deduced (Wikipedia articles, gutenberg.org links etc)
• by someone else's book page that already found an entity to create a book instance in her inventory, but that's just a link to those same entity pages

Otherwise, for what is of making users directly edit Wikidata, it isn't clear at the moment how this should be done or if this can be done, given the Wikidata rules contributors are expected to have in mind when editing. I'm very interested by this discussion though :)

[CloCkWeRX]

Happy to add RDFa or similar to growstuff too; and to assert a crop is an instance of a specific wikipedia (dbpedia? wikidata?) topic.

[simonv3]

@CloCkWeRX What would that look like when you add it to growstuff?

My main concern with the wikidata data is that it doesn't contain links (for example, a tomato) to even any of the sites that Rory just mentioned, except wikipedia, which I feel like loses that benefit right away.

So I imagine that the steps here are:

1. In the crop model, create a links dictionary (is that the best solution? There might be a gem that already does this -> {"name": <name>, "url": <url>, "data": <whatever-data>}).
2. On crop_form, add a search field that uses the wikidata api for suggestions (eg for tomato: https://www.wikidata.org/w/api.php?action=wbsearchentities&search=tomato&language=en&format=json) The question here is whether that will allow CORS, if not then we have to do this via the server, which is a bit of a pain.
3. Store the wikidata ID in our links dict {"name": "wikidata", url: "data-url", "data": Q129"}
4. Show a link to wikidata on the crop page.

We can go from there to search on wikidata for other links, as well as automatically parsing existing crops and linking those crops to wikidata using a script or something like that.

(I know very little about how wikidata works).

[maxlath]

seems that the two possible workaround on that CORS problem are either using JSONP instead of (I have never used is so I can't tell more on that) or, indeed, use a proxy server you trust. In inventaire, I set up a minimal proxy to do just that. request and streams made it quite easy to do in JS, but I don't know how that can look like in Ruby