Proposal talk:Wikidata

From OpenStreetMap Wiki
Jump to navigation Jump to search

Mapp widget

Looks like a good proposal to me, and it seems wikidata tags could replace wikipedia tags. However, for that to happen I think the mapp widget tools that they use on Wikipedia needs a rewrite first. --Guttorm Flatabø (talk) 09:42, 27 February 2013 (UTC)

I'll try to contact the wikipedia widget author to hear his thoughts. Janko (talk) 15:47, 14 March 2013 (UTC)

MacDonalds

Can we find a better example; MacDonalds is a brand, but the operator is usually a franchisee. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:13, 12 March 2013 (UTC)

I replaced operator with franchise and made a new operator section. Janko (talk) 15:43, 14 March 2013 (UTC)
IMHO this franchise:wikidata tag is far too specific, and there is also overlap with other proposed tags. Don't think that we need it or should advocate for this sub tag. --Dieterdreist (talk) 14:17, 6 May 2013 (UTC)
I agree. I'll simply remove it, it's a puzzling example--Danstowell (talk) 16:37, 1 April 2014 (UTC)

Ease of Use

While I support the proposal, and the use of Wikidata, in principle, it's far easier for a non-techie user to find (and tag with) the title of a Wikipedia article, than a Wikidata identity. We need to cater for this, perhaps using a wizard ("did you mean...") at the time of entry; or a script or bot to convert on a, say, nightly basis. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:19, 12 March 2013 (UTC)

For JOSM, this could be integrated with the Tag2Link and Wikipedia plugins. Mrwojo (talk) 02:00, 23 March 2013 (UTC)
A bot or script could also be used to add wikidata=* to all the objects that currently have wikipedia=* (if the article has a Wikidata item), as otherwise it would be rather tedious to do manually and find all 400,000 items with wikipedia=* but not wikidata=*. Jc86035 (talk) 14:32, 23 June 2014 (UTC)

Q

Why do you want the Q (item)? Is there a use for Wikidata predicates (P) in OSM? I think we should simply write wikidata=243. --Reclus (talk) 17:16, 19 March 2013 (UTC)

I think it is more future proof (perhaps there will be more usefull prefixes in wikidata?). And it is easy to explain what to put into the tag.--Zuse (talk) 20:27, 19 March 2013 (UTC)
I'm not sure if predicates could be used in OSM, but who knows. Maybe a relation with type:wikidata=P36 (capital) or something like that. It's probably not going to get used, but why constrain ourselves.
Keep the Q! Much better for futureproofing. --Danstowell (talk) 16:38, 1 April 2014 (UTC)
In any case, it makes it at least slightly easier to tell what value is appropriate. --SamB (talk) 23:01, 22 July 2014 (UTC)

relation to wikipedia=*

Couldn't we simly use the established tag wikipedia=* also for wikidata? Examples: wikipedia=d:Q243, wikipedia:d=Q243; Could there be a bot run that replaces the old tags with tags that point to wikidata? --Reclus (talk) 11:11, 20 March 2013 (UTC)

That would be an easy job, we just have to get the wikidata tag accepted. Janko (talk) 13:01, 20 March 2013 (UTC)
Yes, but why not simply use the widely accepted wikipedia=* also for wikidata? s.a. --Reclus (talk) 13:12, 20 March 2013 (UTC)
There are many reasons, one of which is the first sentence in the proposal: "Connecting Openstreetmap data to Wikipedia articles is not futureproof because there are articles written in more languages and are renamed sometimes.". Second reason is that data miners looking for data with the wikipedia tag cannot do so, because the same meaning can have multiple tags that mean the same thing. For example, if someone is looking for all McDonalds restaurants, they should look for features that have tags: wikipedia=en:McDonald's, wikipedia=de:McDonald's, wikipedia=bn:ম্যাকডোনাল্ড’স and so on. That's not very data miner friendly. With Wikidata tag, you should only look for franchise:wikidata=Q38076, and you get all of them. Janko (talk) 16:24, 20 March 2013 (UTC)
You could do the same with franchise:wikipedia=d:Q38076. --Reclus (talk) 16:34, 20 March 2013 (UTC)
That doesn't sound like a clean solution. A data miner would never know if something is a wikipedia link or a wikidata link. Anyway, nobody says I can't use franchise:wikidata=* right now. The problem is that I want to put it on osm wiki so that everybody starts connecting our data with wikidatas. Janko (talk) 13:21, 21 March 2013 (UTC)
The mapping d:* is supported by wikipedia itself, as they are handling lang:articlename right now. So a data miner does not have to know, if it is wikidata or wikipedia-article (and if he wants to know, he could look if the prefix is 'd'). It simply throws the thing to the Wikipedia API. One problem is, that only articles with multiple languages have an WD entry. So some data could not be converted to WD. On the long run, we should have only one connections to the wikipedia-universe in OSM. So we don't want duplicate connections via Wikidata: and Wikipedia: (as we dont want multiple Wikipedia:lang references in the normal case). Thats why i propose using wikipedia=d:ID for all articles. --Zuse (talk) 13:57, 21 March 2013 (UTC)
Wikipedia articles with only one language version (should) also have Wikidata entries. Just press Edit in Wikipedia and you should see the link to the corresponding WP entry. Example: Bakuninhütte / Q804545 --Reclus (talk) 14:16, 21 March 2013 (UTC)
Thanks for this hint. Available in the german wikipedia via the menu on the left (tools/site information), too.--Zuse (talk) 14:26, 21 March 2013 (UTC)
I didn't know about the lang:* and d:* calls to Wikipedia api. If that is right, I'm ok with that. Only problem I see is data consumers that are using the wikipedia tag right now. Do they know about d:*? What if they are not using the wikipedia api but just making the link by themselves?Janko (talk) 21:26, 23 March 2013 (UTC)
They have to update their code. I think we should discuss the topic on the mailing list and try to change the wikipedia=* article. The most important applications for me are WIWOSM and WikiMiniAtlas, which both display ways/nodes/relations tagged with wikipedia=* red. Perhaps we should contact the developers directly. For operator:wikipedia=* etc.: There is a proposal for wikipedia:operator. --Reclus (talk) 12:57, 24 March 2013 (UTC)
I'm one of the developers behind WIWOSM.
For the question which tagging is more futureproof I disagree with the statement here, Wikidata is really young project and a lot of things can happen, on the other side are Wikipedia tags relative stable over the last years. An other argument for Wikipedia-tags is that they are humane-readable (Ok, as long the skript is readable you, but in most cast better than to read Q38076 or so.). I believe this is import if you work with thousands of volunteers on both sides. So please don't replace Wikipedia-Tags by Wikidata-Tags and give the process enough time.
Don't understand me wrong, I love Wikidata and want to support it. Especially if we will see in next pühase of wikidata that we have millions of entries in wikidata that are used to generate lists in Wikipedia and have so no own article, we have perhaps no other chance than to link to Wikidata.
Two weeks ago we check that we can easily use for WIWOSM the interwikilinks in Wikidata github-diff. As far as I can see we can also use very easy the wikipedia=d:Q1234-Tag, but I would do this only if no Wikipedia-article is available.
Two other things: To link Wikidata with OpenStreetMap also the other direction would be theoretically possible, but it's in my eyes not useful to link from Wikidata to unstable collections of OSM id's. So this way is better.
Second thing is that I know that Wikidata want later also support geodata like coordinates but also shapes in geoJSON. For legal reasons they can not use OSM-ODBL data in there CC-0 database. To not double the effort, I see only usecases for things that are out of scope for OSM and things with a lower level of details. But there we will have interesting discussion in the future. --Kolossos (talk) 20:10, 28 March 2013 (UTC)
BTW: We can access an Wikidata entry also e.g. by: http://www.wikidata.org/wiki/Special:ItemByTitle/dewiki/Berlin ,so we can leave it human readable. --Kolossos (talk) 12:10, 29 March 2013 (UTC)
No, no, no. This is terrible idea, Wikipedia tag has a clear meaning and this proposed hijacking is harmful as would disrupt everybody processing this data. Bulwersator (talk) 12:16, 3 March 2014 (UTC)
No, please do NOT reuse wikipedia tag for wikidata entries. There are good reasons why an object may be tagged with both -- especially in the transitional period when some data consumers make use of one, and some make use of the other. --Danstowell (talk) 16:40, 1 April 2014 (UTC)
In addition to the above, Wikipedia has articles such as https://en.wikipedia.org/wiki/Q102 - the potential for confusion would be too great. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:21, 1 April 2014 (UTC)

etymology spelling

I'm not a native speaker, but I think that the word should be written et*y*mology. --Tordanik 15:27, 6 May 2013 (UTC)

You're correct; I've fixed that. Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:04, 12 September 2013 (UTC)

Adding Wikipedia/ Wikidata tags automatically

I'm working on a proposal to automate the addition of Wikipedia tags to some OSM features. This could also include Wikidata tags. Please see User:Pigsonthewing/Wikipedia and comment on the talk page there. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 07:58, 12 September 2013 (UTC)

Comparison with structure of Wikipedia tag

We propose, for example wikipedia:subject=lang:*, but also subject:wikidata=*.

Should the latter not be wikidata:subject=* for consistency? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:31, 24 September 2013 (UTC)

Yes. But it could also be/stay wikipedia:subject=lang:* with d:-Prefix for wikidata. --Reclus (talk) 13:22, 24 September 2013 (UTC)
In the case of the wikipedia tags, some have pointed out that putting the postfix at the end makes it harder to distinguish from a language code. So perhaps we should instead unify towards to subject:wikipedia=...? --Tordanik 12:30, 25 September 2013 (UTC)

Optional use besides wikipedia tag

Looks very nice, especially when you think of the opportunities of the possible connections with Wikidata. But as Wikidata is a young project that first has to be finalized, I propose to use the wikidata-tag in the first time optional to the wikipedia-tag. --Chinus (talk) 23:49, 12 December 2013 (UTC)

The wikidata-tag is in the moment redundant to the wikipedia-tag. And an absolutely redundant tag is useless and only a source of inconsistencies and errors. Also for programmers it's very easy to get a connection to wikidata over the wikipedia-Tag by using the API. Here is one Example:
--Kolossos (talk) 20:50, 8 March 2014 (UTC)
The wikidata tag is not redundant with the wikipedia tag. For example, some objects will be linked to specific language pages on wikipedia, while the wikidata tag doesn't capture this. Also, some data consumers will make use of one, some of the other. I certainly agree that wikidata tag is optional. In its use-cases, it has some overlap with wikipedia tag but not complete overlap. So no need to worry. Just let both tags coexist. --Danstowell (talk) 16:44, 1 April 2014 (UTC)

Progress

How do we move this from a proposal to a published key? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:05, 1 April 2014 (UTC)

Well, the process is described here: Proposed features. Looks like the next stage is to change it to "Proposed" and RFC it.--Danstowell (talk) 16:34, 1 April 2014 (UTC)
OK, that's done. Thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:08, 1 April 2014 (UTC)

Order of parts

I've been using, say wikidata:architect=*, but the proposal currently recommends architect:wikidata=*. Aside from personal preference, is there a reason to favour one over the other? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:12, 1 April 2014 (UTC)

I've been experimenting with wikidata tags and having artist, architect, name:etymology first sorts them near to artist_name, name etc. This makes verification easier if one day the editor software will resolve the Q-numbers to wikidata labels.
--Polyglot (talk) 17:50, 1 April 2014 (UTC)
An argument for wikidata:architect would be consistency with the wikipedia tags. Although someone has edited the Key:wikipedia page claiming a controversy about the order, this isn't reflected in the database where wikipedia:architect/subject are prevalent.
Personally, I think both would work equally well, though. --Tordanik 21:36, 1 April 2014 (UTC)
I like xxx:wikidata because you can have other tags regarding the tag. For example operator:wikidata, operator:source, operator:phone, operator:website. It just looks better structured to me. Wikidata is the attribute of operator, not the other way around. Janko (talk) 09:43, 2 April 2014 (UTC)
There is a good argument to wikidata:architect=* instead of architect:wikidata=*: The first key is the "namespace" of the key, and it's what the value is really about . The keys source=* and wikipedia=* are well-established precedents of this. A program would have to guess to understand some variations of anything:wikidata=* (especially on more complex cases like name:etymology:wikidata=*). --Jgpacker (talk) 00:26, 4 May 2014 (UTC)
I see no reason why a postfix would be harder to recognize for a program than a prefix? --Tordanik 07:31, 4 May 2014 (UTC)
I said that thinking of documentation linking (interwiki and from other sites do this wiki). Indeed a program that is looking for wikidata tags could assume that any key with "wikidata" on it would link to a wikidata page (a program made specifically to recognize such links). But when linking to the documentation page, what matters is what the value is about, and although this is not implemented yet in most sites, the program could assume that the first part (or the 1st+2nd if the key has 3 parts) of a complex key is where the documentation is at (when there is not a wiki page for the whole key). --Jgpacker (talk) 12:52, 4 May 2014 (UTC)
Is there a tool or template which gives a quick comparison of the usage of two tags? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:51, 2 April 2014 (UTC)
There is Taginfo[1] and there's 161 operator:wikidata already in there. Janko (talk) 12:15, 2 April 2014 (UTC)
With source:operator and wikipedia:operator the situation on taginfo is reversed, though. So the sorting won't work unless we also change the order recommended on Key:source, at least. --Tordanik 13:27, 2 April 2014 (UTC)
Thank you; I meant a side-by-side comparison of two (or more) tags. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:00, 2 April 2014 (UTC)
I see these as slightly different, source=* and tags of the form source:* are effectively metadata tags (tags about how the data were acquired) whereas things like operator:wikipedia are genuine data tags. In other words I think that the sensible grouping rules are different and that postfixes make sense for data tags as Polyglot suggests, but using a prefix for keeping metadata together also makes sense. See also *:count which is a postfix style annotation to the base tag. Broadly I think we can have our cake and eat it. SK53 (talk) 10:00, 3 April 2014 (UTC)

Renamed pages

One of the motivators behind this is the bogeyman of a Wikipedia page being renamed; one might worry that the OSM element will point to a non-existent article! However, looking at what actually happens, we see in step 3 that "The old title will become a redirect page, so any links to the old title will still go to the new page." --goldfndr (talk) 02:24, 2 April 2014 (UTC)

If an editor renames 'John Doe' to 'John Doe (actor)' there will indeed be a redirect from the former to the latter, but that editor or another will often then overwrite that redirect with an article about, say, John Doe the (better-known) politician; or a disambiguation page which links to both 'John Doe (actor)' and 'John Doe (politician)'. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 09:32, 2 April 2014 (UTC)
Could you give an example (or three) of when that's actually happened with a wikipedia=* tag's target? (I'd hoped, in the WIWOSM article, to find statistics on links that point to redirects -- as that'd be a warning that what you suggest might occur -- but I didn't spot any.) --goldfndr (talk) 05:13, 3 April 2014 (UTC)
https://en.wikipedia.org/wiki/Handsworth used to be about the place in South Yorkshire, That was then moved to https://en.wikipedia.org/wiki/Handsworth,_South_Yorkshire and the page at the original URL became a redirect. Shortly afterwards, this was changed to a disambiguation page ([2]). it is not the redirect, but the later reuse, that is the issue. using Wikidata identifiers avoids this. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:24, 9 April 2014 (UTC)
Wikidata entries are probably more stable than Wikipedia article names, but, as far as I can see, they could still be deleted or forgotten (leading to duplicate items, one of which is not maintained). I am thinking that a monitoring tool, which warns OSM people when a Wikipedia article that is referenced in the OSM database is moved, would be a more suitable solution to this problem. Augusto S (talk) 13:46, 25 June 2014 (UTC)

Franchise

Why has the wikidata:franchise/ franchise:wikidata sub-tag been removed from this page? I've restored it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:03, 2 April 2014 (UTC)

perhaps brand would be better. Will have less typos and is used in amenity=fuel. --Zuse (talk) 10:44, 2 April 2014 (UTC)
Yes, that may well be better. Suggest we merge them in a day or two if there is no dissent. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:49, 2 April 2014 (UTC)

Tombstones

Is it correct to use subject:wikidata for tombstones, i.e. are they considered memorials? What if there is artwork on the tombstone/shrine depicting a different subject?

What if one tomb serves for more than one deceased person? Do we start using Q1;Q234 ?

I think that is ok, but only if it at least slightly resembles artwork. I don't think we should link subjects to people because there is a photograph or a name on the tombstone. That should be a different tag, like buried:wikidata=*. Using a semicolon for more values is IMHO a good practice, except for wikidata=*. There should be only one of those. Janko (talk) 10:50, 23 April 2014 (UTC)

OSM is a standalone database

You write : "Openstreetmap could focus more on placing certain features in the geospatial world, and Wikidata would be responsible for various feature attributes and relations". It is really out-of-question that OSM will ever move "attributes or relations" into wikidata/wikipedia. OSM is a standalone project and has to be able to work and progress without any wikidata or any external database dependencies. --Pieren (talk) 13:14, 2 April 2014 (UTC)

For basic data/relations this may be possible, but some relations are really out of the scope of OSM. How people relate to each other/family ties. Which 'notable' persons had a University as their alma mater. That's not something we aim to record ourselves. Or say you wanted to find all the artwork worldwide that has the archangel Gabriel as its subject. Overpass can't help there anymore either, due to differences in spelling across languages.
For simple translation of the toponyms we will probably keep all those translations ourselves, but we can make use of wikidata to do some validation and cross-pollination of the lists there too.
I do think we should keep using artist_name and artist:wikidata next to each other in OSM, but at least those artist:wikidata tags will be different when the names might be shared by more than one person.--Polyglot (talk) 13:49, 2 April 2014 (UTC)
The paragraph you cite continues with discussion of "complex querys like 'find all cities which are no further than 10km from the sea, and have a female mayor'"; I doubt anyone would suggest tagging OSM entities with the gender of the civic leader. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:49, 2 April 2014 (UTC)

Linking to specific sections of articles

As far as I understood, a lot of people aim to replace the wikipedia=* in the long term. In some cases, there may be a need to reference a specific section of an wikipedia page (because there isn't a single wikipedia page for that object), for example [wikipedia=en:WWVB#Antennas]. How would wikidata=* handle that? --Jgpacker (talk) 14:19, 2 April 2014 (UTC)

I don't suggest deprecation of wikipedia=*; particularly in such cases. Note, though, that URLs for sections of Wikipedia articles are even less stable than Wikipedia article URLs. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:44, 2 April 2014 (UTC)
Also note that it's almost impossible (to create an algorithm) to find the counterparts in other language WPs. I think this would merit a separate wikidata entry. --Polyglot (talk) 14:47, 2 April 2014 (UTC)
I agree, the right way would be to make a new wikidata entry Janko (talk) 09:08, 23 April 2014 (UTC)
The current Wikipedia tag doesn't support such values also --4rch (talk) 13:46, 3 April 2014 (UTC)

More specific

What exactly means »There shouldn't be more than one Openstreetmap item with the same Wikidata ID«? Please state exactly, under which conditions it is allowed and when we must not have 2 or more objects with the same Wikidata ID. If unsure, state the drawbacks of 1:n-relations for this tag so we have a common ground to discuss things on. --Nadjita (talk) 12:33, 9 April 2014 (UTC)

There is no drawbacks, and I'm sure. There should be only one wikidata + distinct value in our database. For example, there should be only one "wikidata=Q243" (Eiffel tower) tag in our database. No two entities (nodes, ways or relations) can have the same wikidata=* tag.
Composite tags are something else. There can be more features with the same artist:wikidata=* tags. That's because there are more than one sculptures made by the same artist. But if you have a wikidata item that represents a sculpture, then there is only one sculpture that deserves that particular wikidata=*.
I hope I was clear. Janko (talk) 11:00, 23 April 2014 (UTC)
In the process of adding wikidata-tags to all items with wikipedia-tags, I encountered several duplicates.
Example 1: There is a street with a wikipedia-entry, the tag gets duplicated every time the road is split because of speed/surface-changes. The only way to work around duplicate wikidata-tagging would be to use a street-relation. That one's not approved and I'm not even sure it would work as expected.
Example 2 would be something like a Goethe-Institut: a private organisation that runs language-schools in many countries. Many many of them like to "en:Goethe-Institut". Should that really be converted into brand:wikidata=en:Goethe-Institut? I don't think that's a brand.
Example 3: is something the German Post calls "Paketzentrum" (package-hubs). Nearly all buildings that ae hubs refer to the wikipedia-article "de:Paketzentrum (Deutsche Post DHL)". How would we deal with something like this where an article describes n objects in the OSM-database? It's not a brand (that would be Deutsche Post DHL, but not Paetzentrum), so what is it?
I fear that forbidding duplicate entries will a) lead to several inconsistencies as long as it is okay to use the wikipedia-tag on several objects and b) be impossible to maintain as long as nothing prevents people to uploading this data to OSM.
If you still think it must not be allowed, please replace "shouldn't" with "must not" and add many detailed examples for solutions of problematic cases like the ones I gave.
Example 1 is a valid counterexample imo, but the other two aren't. These objects are a Goethe-Institut and a Paketzentrum, respectively, not the Goethe-Institut/Paketzentrum. Therefore, an unprefixed wikidata tag is not approrpiate. (The same is true for wikipedia tags, bur example 2, y the way.) In the case of the Goethe-Institut, I would be inclined to use the operator prefix, because the wikidata item explicitly represents the association that operates these facilities. I'm not sure about the Paketzentrum. --Tordanik 07:08, 28 April 2014 (UTC)
Even a road with a dividing barrier in the middle would have to have at least two segments, so multiple Wikidata tags can definitely be used for that. As for example 3 I think that's not actually the correct usage because the article isn't about a specific Paketzentrum. (see also Key:wikipedia § Using Wikipedia links) Jc86035 (talk) 13:01, 23 June 2014 (UTC)

There are three potential kinds of links:

  • objects which we map as a single entity, which relate to single Wikidata entry: e.g. bridges, buildings, statues
  • objects which do not relate to single Wikidata entry, but which have a property which refers to a Wikidata entry: e.g. statues (sculptor=; subject=), buildings (architect=; operator=)
  • objects which we map as several parts, but which relate to single Wikidata entry: e.g. rivers, roads

I would argue that the latter should have a single relationship which refers to the Wikidata entity. If they don't then we could use, say, route:wikidata=.

As noted above, your example 2, Goethe-Institut, should use operator:wikidata=.

In short, wikidata= should be unique, but foo:wikidata= need not be. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:11, 23 June 2014 (UTC)

Again, there are bridges with central dividers, multiple rail tracks, cycleways and walkways, etc.. So those would probably use route:wikidata=*, would they? Jc86035 (talk) 14:18, 23 June 2014 (UTC)
That depends on how it's mapped. Do you have some specific examples in mind? If there is one entity for "the bridge", with others overlaid on it, then that single entity should be tagged. Otherwise, the next preference should be a relation. After that, we could use something like bridge:wikidata=*. Alternatively, perhaps we should tag only the entity (e.g. https://www.openstreetmap.org/way/3390433 ) which carries the name? While this needs to be decided, it shouldn't stop us, in the meantime, from tagging simpler cases, such as https://www.openstreetmap.org/way/22887949 Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:58, 23 June 2014 (UTC)
I think something like road:wikidata=* would work as well, as relations can't be added to non-trunk route/motorway ones. tunnel:wikidata=* would also work. Jc86035 (talk) 09:53, 24 June 2014 (UTC)
In the case of tunnel, I really think that the famous ones should just get their own area or relation, which also has several other benefits. For roads, I agree that something like road:wikidata would be a solution. --Tordanik 21:03, 24 June 2014 (UTC)

WIWOSM

Would we have to modify WIWOSM to take this tag into account? Jc86035 (talk) 08:44, 23 April 2014 (UTC)

There can be a few changes added. You can add the basic wikidata=* tag to WIWOSM and show where something is. But you can also add artist:wikidata=*, and show where someone can see artwork made by the subject of the article. Architect:wikidata shows buildings made by a certain architect. I think this could be a great resource for Wikipedia. It will also make people map these features more, because they can see it rendered. Janko (talk) 09:06, 23 April 2014 (UTC)
If only they would add it to the English Wikipedia... It has about as much traffic as all the other Wikipedias combined. Jc86035 (talk) 11:24, 26 April 2014 (UTC)

Voting

Should be the voting process be started about now, given that there's been no discussion for the last four weeks? Jc86035 (talk) 09:05, 22 May 2014 (UTC)

I think this topic: #More specific should be solved before the voting process. --4rch (talk) 12:26, 17 June 2014 (UTC)
Yes, as soon as possible, if we really need a vote - but do we? People are using the tags already; we can agree how they should best be used, by consensus here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:15, 23 June 2014 (UTC)
The illusion of bureaucracy must be maintained. —Tom Morris (talk) 14:51, 7 July 2014 (UTC)

Isn't OSM already linked to Wikidata?

Wikipedia articles can be/are already linked to the corresponding Wikidata entry. In this sense, wikipedia=en:Dubrovnik is just a human-readable version of wikidata=Q1722 wikidata=Q1722 is just a human-unreadable version of wikipedia=en:Dubrovnik. In particular, OSM has already a lot of connections to Wikidata. Of course this would require applications which want to access Wikidata to do an extra step, namely quering Wikipedia for the corresponding Wikidata entry. But if you are already doing the work of parsing Wikidata entries, doing this extra step doesn't seem too much of a burden. Augusto S (talk) 13:40, 25 June 2014 (UTC)

See #Renamed pages. As stated there, Wikipedia pages may be moved, and the redirect which OSM links to can be turned into something else, like a disambiguation page, thus breaking the link. Jc86035 (talk) 14:08, 25 June 2014 (UTC)
I have already made my remarks about #Renamed pages in that thread. In this thread, I would like to discuss the claim made in this proposal about "connecting our data with Wikidata's". More specifically, I am arguing that such connection is already in place. Augusto S (talk) 16:05, 25 June 2014 (UTC)
No, OSM is not completely linked with Wikidata because Wikipedia and Wikidata have no 1:1 relation. For example there's only one Wikipedia article about Heligoland but you need two objects if you want to model this logically: municipality Heligoland island Heligoland. It's also possible that there's completely no Wikipedia article about an object. --4rch (talk) 18:23, 25 June 2014 (UTC)
I completely agree that it makes sense to add a Wikidata link when a Wikipedia article does not exist. However, there does seem to exist a (partial) univocal mapping Wikipedia -> Wikidata: look for the "Data item" link in Wikipedia's left panel.
The Wikipedia article Heligoland clearly refers to the municipality: it mentions the mayor, population, postal code, etc. And, in fact, if you open the article and click "Data item", you will see it links to Q3038 (the same is true for the German article). Since OSM relation corresponding to the relation municipalty of Heligoland points to de:Helgoland, the wikidata tag there is completely redundant; on the other hand, the relation corresponding to the relation island of Heligoland has tags wikipedia=de:Helgoland and wikidata=Q17043877, which can be considered an incosistency, since de:Helgoland does not point to Q17043877 in Wikidata. The conclusion I draw from this example is that wikipedia and wikidata tags should never coexist: it's a redundancy at best, and may lead to inconsistency. Augusto S (talk) 19:45, 25 June 2014 (UTC)
Inconsistency you'll get when you try to combine both tags. For example when you add only there Wikidata-ID's when there's no Wikipedia link and try to compute the missing Wikidata-ID's via the Wikipedia links. That's not a good idea. Wikidata is a standalone project. Links to Wikipedia articles and the replacement of Interwikilinks is just one advantage of Wikidata. --4rch (talk) 09:41, 5 July 2014 (UTC)

xxx:wikidata, seriously?

Looking at taginfo for artist:wikidata=* , I found a lot of Q3364484, all nodes with also the tag artist_name='Johannes Wiedewelt'. Some memorials and artworks, if you want to know.

Now, on wikidata, http://www.wikidata.org/wiki/Q3364484 leads to (guess who ?) ... Johannes Wiedewelt related page. Again, on wikidata search form, if I search for 'Johannes Wiedewelt', guess what page I found ? http://www.wikidata.org/wiki/Q3364484.

I really wonder ... what's the point of adding artist:wikidata=Q3364484 in OSM? If people are interested in Johannes Wiedewelt in various databases, the natural key is 'Johannes Wiedewelt'. Isn't this wonderfully efficient, and easy enough ?--Yvecai (talk) 19:13, 1 July 2014 (UTC)

Not all people have an unique name. What about "Friedrich Schiller" – is it the poet, the lawyer, or the soccer player? "Hans Albers" – the actor or the manager? Then there are different possible spellings and variants which might mess up the search result: "Friedrich Schiller", "Friedrich von Schiller", "Schiller, Friedrich", "Johann Christoph Friedrich von Schiller". And even if a name is unique right now, that may no longer be the case tomorrow – a duplicate is just one birth, just one marriage, just one name change away. So I hope this answers your question why names are bad database keys. --Tordanik 22:46, 1 July 2014 (UTC)
wikipedia found a solution (page title is unique). If you use the same name as wikipedia in the 'artist_name' tag (or use wikipedia url tag), that's enough. I get the impression that some people use a wikidata key just because they are not allowed to use a relation (relations are not categories). At most, add one wikidata tag and get all the details you want like construction dates, artist or architect names, material, colours, and so on into you external database but not in OSM which is a spatial database, not an encyclopedia. --Pieren (talk) 15:25, 2 July 2014 (UTC)
"(Wikipedia) page title is unique" but not stable. For example, if a person with the name 'Johannes Wiedewelt' is elected as a leader of a large country it is very likely that the artist article is renamed and the politician gets the main title.--Zuse (talk) 07:11, 3 July 2014 (UTC)
Some people claimed (in this page) that Wikipedia article names don't change all that often. Moreover, Wikidata entries are also not guaranteed to be stable: items can be deleted, merged, etc (here is an example of duplicate entries, which are likely to end up being merged at some point: http://www.wikidata.org/wiki/Q3364110 and http://www.wikidata.org/wiki/Q10344990). So this argument you gave only has any weight if you can convince people that 1) article name changes in Wikipedia are a serious issue from OSM's perspective and 2) wikidata changes are substancially less problematic. I am not convinced of either of these points. Augusto S (talk) 22:27, 3 July 2014 (UTC)
Renaming wikipedia pages is an everyday occurrence. It's not even considered a bad thing – replacing a page with a disambiguation page when more persons or things with that name become notable is common practice, for example. Merging of Wikidata items, on the other hand, only occurs when someone has made a mistake.
Wikidata IDs are also more stable in the sense that they will not be reused for something else: Once an item has been deleted, that ID is not used again (which allows us to spot problematic links easier).
I also wonder what this has to do specifically with the topic of xxx:wikidata keys. Doesn't this apply to all wikidata links? --Tordanik 07:46, 4 July 2014 (UTC)
It's already under development that merged WD-Items redirect to the object they've got merged with. --4rch (talk) 09:26, 5 July 2014 (UTC)
If people are interested in John Smith in various databases, the natural key is 'John Smith'. Reductio ad absurdum-ed that for you. —Tom Morris (talk) 14:47, 7 July 2014 (UTC)

Display

Wikidata values are now displayed, and linked in OSM's browse-helper pages see for example: http://www.openstreetmap.org/way/15239807 Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:32, 21 July 2014 (UTC)

one of the cool features of wikidata that doesn't get enough publicity is that Internationalisation is automatic and Localisation is simple. It could be nice if the next iteration of this tool would give the value of "name:etymology:wikidata" as "William Baldwin" for english speakers instead of 'Q8004980' and for speakers of other languages would display the appropriate wikidata label for their language. While 'William Baldwin' doesn't change much from language to language the same is not true for other tags and piggybacking off the localisation work by wikidata would seem to be a good use of resources. Filceolaire (talk) 18:38, 20 August 2015 (UTC)

Do NOT use name:something

Whatever you do NOT use name:SOMETHING as tags. It looks too much like the usual name:LANGUAGE. A computer can't differentiate betweeen those uses.

Joto (talk) 15:14, 31 July 2015 (UTC)

This issue is unfortunately becoming increasingly hard to avoid. Currently, we use name:etymology:wikipedia, making it look similar to the common name:LANGUAGE. Alternatively, we could use wikipedia:etymology:name, thus making it look similar to the common wikipedia:LANGUAGE. At the root of the issue is the growing number of keys that can be extended with a language suffix.
Based on your experience, would it be possible to make distinguish the two cases based on the length of the substring? Non-language substrings should be longer than the 2- or 3-letter ISO codes. --Tordanik 15:55, 31 July 2015 (UTC)
As mentioned by Sarah in talk@, there are also name:ko_rm (150.000 occurences), name:sr-Latn, name:kn:iso15919, name:right/left, name:genitive/adjective, all of them relevant to a geocoder. --Fschmidt (talk) 18:15, 4 August 2015 (UTC)

Which wikidata properties do these correspond to?

Once we have the "wikidata=q??????" tag attached we can then import statements about that item from wikidata like the population, the flag, the coat of arms, twin towns etc. The Operator:wikidata tag and the other similar tags seem to be trying to duplicate that function of wikidata by defining a set of OSM tags that sort of duplicate Wikidata properties. 'name:etymology:wikidata=*' is pretty much a duplicate of wikidata property 'named after (P138)' (but not quite).

Would it be better for OSM to just import the info from Wikidata? Filceolaire (talk) 19:05, 20 August 2015 (UTC)

Using a wikidata tag is useful precisely because it allows OSM-based software (renderers etc.) to access such information without having to import it in OSM. So we shouldn't import wikidata information. Unless I misunderstood your suggestion, of course. --Tordanik 09:04, 21 August 2015 (UTC)
Thanks Tordanik. I see now I was misunderstanding the difference between the first tag 'wikidata=*' which will link to the wikidata item for the specific OSM item and the other tags which will link to generic wikidata items. Filceolaire (talk) 01:00, 27 August 2015 (UTC)

"Every country has its own operators, and two countries can't have the same operator"

Can somebody explain meaning of this sentence? Is it claiming that each value of wikidata:operator may be present only in one country? It is weird, given that there is plenty of entities operating in multiple countries Mateusz Konieczny (talk) 07:34, 14 October 2015 (UTC)

I also find that sentence confusing, and I'm not sure what countries even have to do with operators. --Tordanik 13:51, 15 October 2015 (UTC)
Removed Mateusz Konieczny (talk) 08:23, 12 September 2017 (UTC)

Commemorates or subject?

Do you folks see a difference between commemorates:wikidata=* and subject:wikidata=*? Currently the page for historic=monument seems to recommend the former. I wonder if both can coexist. Pizzaiolo (talk) 21:58, 3 February 2017 (UTC)

A possible distinction would be that subject is what the artwork depicts, which might be different from what it commemorates. Not sure if it's used like that, though. --Tordanik 19:32, 21 February 2017 (UTC)

OSM+Wikidata database, queries, etc.

The new SPARQL service combines both OSM and Wikidata inside one database. We could start a catalog of queries that would recommend renaming of "wikidata" → "species:wikidata" when it is an instance of "Taxon" (for example). See the service in action. P.S. I started writing Wikidata Classification Guide, and then discovered this page. Guess I should merge in :) --Yurik (talk) 07:08, 12 September 2017 (UTC)

Shouldn't we use brand:* instead of network:* ?

I think network:* is conceptually indistinguishable from a brand name, and therefor should not exist as a separate type of tags. --Yurik (talk) 00:44, 26 September 2017 (UTC)

Have a look at the wiki page for the network tag and see how diverse its use is. For public transport this is not the same as brand.

--Polyglot (talk) 04:31, 26 September 2017 (UTC)

Thanks Polyglot, yeah, some of it, like roads, really wouldn't fit the brand. I guess it is better to keep consistency with the existing tag, rather than move just the companies like Muni and SORTA to brands. Thanks for the comment! --Yurik (talk) 04:41, 26 September 2017 (UTC)

Archiving this proposal

Adding Wikidata tags has become established practice and the key (including all the secondary keys) is properly documented on Key:wikidata. I believe this proposal page has therefore fulfilled its purpose. If there are no objections, I'll add a {{No vote feature link}} template on top and archive it. --Tordanik 18:44, 22 March 2019 (UTC)

I support doing this Mateusz Konieczny (talk) 13:39, 23 March 2019 (UTC)
I agree. --Władysław Komorek (talk) 14:09, 23 March 2019 (UTC)
Ok, done! --Tordanik 17:56, 25 March 2019 (UTC)