Wikidata

Wikidata:Project chat/Archive/2013/07

< Wikidata:Project chat‎ | Archive‎ | 2013
This page is an archive. Please do not modify it. Use the current page, even to continue an old discussion.

Gregorio Correr

This must be linked with w it, n82101672 --Oursana (talk) 10:07, 1 July 2013 (UTC)

  Done I've merged Q5606717 into Q3765384. Thanks. Del♉sion23 (talk) 14:20, 1 July 2013 (UTC)

Merging of items with same Commons category

There is more than 700,000 statements with Commons category (P373) imported from different Wikipedias, so I thought that items with duplicate values for Commons category (P373) in many cases can be merged. You will find a list at User:Byrial/commonsmerge with merge candidates for 1778 shared values for Commons category. For each value there is one or more items with links to en: but not to de:, and one or more items with links to de: but not to en:, and the two groups of items should never have links to the same language, so I guess that many of the listed items can be merged, what you are welcome to do. Byrial (talk) 00:37, 28 June 2013 (UTC)

Good idea. I've gone through a few and while most can be merged, there's a fair portion of non-obvious cases. If it's not too complicated, could you split the list between items for categories and items for articles? Articles seem like a higher priority. Thanks, Pichpich (talk) 05:40, 28 June 2013 (UTC)
  Done Byrial (talk) 07:39, 28 June 2013 (UTC)
These lists can of course also be made for other language combinations than English and German. I made User:Byrial/commonsmerge/fr for de-fr, en-fr and es-fr, and User:Byrial/commonsmerge/fi for en-fi and sv-fi. I can make others on request. Byrial (talk) 09:34, 28 June 2013 (UTC)
Great idea, would you want to make a list for nl-wiki? Thanks in advance, Foxie001 (talk) 09:46, 28 June 2013 (UTC)
  Done: User:Byrial/commonsmerge/nl. I saw in your babel box that you also speak (some) English, French and German, so I made lists for these languages vs. Dutch. Byrial (talk) 10:37, 28 June 2013 (UTC)
very helpful. thanks! Holger1959 (talk) 10:48, 28 June 2013 (UTC)
Would you be able to do Czech (cs), while you are at it? Littledogboy (talk) 17:59, 1 July 2013 (UTC)
  Done. At User:Byrial/commonsmerge/cs you will find Czech vs. English, Spanish, Slovak and Polish. Byrial (talk) 20:16, 1 July 2013 (UTC)
Sweet! Not as bad as I thought, though... Littledogboy (talk) 20:59, 1 July 2013 (UTC)
Also, Spanish would be nice (please, please, please). Andreasm háblame / just talk to me 22:53, 1 July 2013 (UTC)
  Done at User:Byrial/commonsmerge/es. "es-en" and "es-de" have many entries, but also already many red links (properly merged from lists of "de" and "en" vs. other languages). You will also find "es-fr", "es-it", "es-nl" and "es-pt". Byrial (talk) 23:41, 1 July 2013 (UTC)
Thanks!!! Andreasm háblame / just talk to me 02:20, 2 July 2013 (UTC)

Double Q-identity

Today I have created a new Q13581188 for de:Alebrijes de Oaxaca FC to link it with es:Club de Fútbol Alebrijes de Oaxaca but this has already a number which is Q5887994. Could anyone help to merge these links? Thank you in advance and best regards, --Chivista (talk) 20:12, 1 July 2013 (UTC)

  Done. You should add interlanglink to article without any links directly in wikipedia page - simply in de:Alebrijes de Oaxaca FC add langcode es and corrct link - item will be merged. JAn Dudík (talk) 20:21, 1 July 2013 (UTC)

How do I go about merging two classes?

I'd like to merge Q765157 and Q10788660. Thanks 110.67.148.4 13:05, 23 June 2013 (UTC)

→ Merge.js. --Ricordisamoa 13:18, 23 June 2013 (UTC)
Thanks, too hard for me. How do I request a merge? :-) 110.67.148.4 13:22, 23 June 2013 (UTC)
I went ahead and merged it. There probably should be a better place for people to request merges that don't know how and/or can't (IP users can't use gadgets, for example). The Anonymouse (talk) 01:40, 24 June 2013 (UTC)
Wikidata:Interwiki conflicts‎ doesn't seem like an appropriate place :( Perhaps we should create a Wikidata:Requests_for_mergers in a similar style to Wikidata:Requests_for_deletions? ·addshore· talk to me! 22:54, 25 June 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

After looking at this a bit more I have actually spotted that the top of this page says Requests for deletions and mergers can be made here.(linking to requests for deletion). I guess the plan was to have mergers and deletion requests all requested on the same page. As RFD seems to be getting busier and busier is this something that we would maybe want to change? ·addshore· talk to me! 16:01, 29 June 2013 (UTC)
  •   Support I would support having a page like request for merging. Because leave out regular users and think about those who came here surfing and somehow (don't ask how) spotted duplicate items; will they go through merging the item or would like to put a request for someone to merge them. I would certainly put a request of merge rather then going for merging myself.--Vyom25 (talk) 12:01, 2 July 2013 (UTC)
  •   Support It would both 1) Give inexperienced users a location in which to get a merge completed successfully without cluttering RfD, and 2) have the potential to act as a discussion place for potential mergers in which consensus can be reached. Del♉sion23 (talk) 13:08, 2 July 2013 (UTC)

Statistic of Common Interwiki links

I do not know whether anyone here have suggested before. As all interwiki data has been centralized in Wikidata now, I suppose it would not difficult to generate the statistic of "Common Interwiki links" (articles which have the most interlanguage links but no link to a language version) for every language version. There was a page in Meta which did the same thing (m:Common Interwiki links) before the establishment of Wikidata, but it has been inactive for a long long time. -- Kevinhksouth (talk) 13:46, 30 June 2013 (UTC)

Such a page exists already: Wikidata:Database_reports/Missing_links --Pasleim (talk) 13:58, 30 June 2013 (UTC)
Thanks for your link. Unfortunately, it does not include zhwiki, which I mainly concern for. -- Kevinhksouth (talk) 14:15, 30 June 2013 (UTC)
Kevinhksouth, according to the bot discussion page, you can add language like zhwiki in the input page. You only need to be an autoconfirmed user rights to edit the page. --Napoleon.tan (talk) 07:59, 1 July 2013 (UTC)
Thanks for your information. Still unfortunately, I just have a few edits in Wikidata but it requires 50 edits. I may have to find others in zhwiki to help. Thanks anyway. -- Kevinhksouth (talk) 14:04, 1 July 2013 (UTC)
If you are interested I can make a special list for you with items which have links to certain languages (for example zh-yue or any other you name) but not to zh. I could also select items without zh link based on which statements they have or other things. Just come with your ideas. Byrial (talk) 14:46, 1 July 2013 (UTC)
Thank you for your help. Is it possible to make two lists, one with items (only in article namespace, except disambiguation pages) which have link to en but not to zh and have at least 15 language links, and another with items (also in article namespace only, except disambiguation pages) which have link to zh-yue but not to zh and have at least 2 language links (at least 1 language link besides zh-yue)? If there are too many results, just top 500 or even top 100 is still fine. If only one list can be generated, please generate the former one, as it seems more useful. Thanks. -- Kevinhksouth (talk) 13:06, 2 July 2013 (UTC)
  Done at User:Byrial/zh. I removed items which have a statement P107 (P107) = Q11651459 but there may be some disambiguation pages which do not have that statement, and therefore still are on the lists.
That's great! Thank you very much! -- Kevinhksouth (talk) 15:27, 2 July 2013 (UTC)

New value setting proposal

Currently, all statements and qualifiers can have a value set to one of three value settings: "custom value" (an item, datetime, string, etc. depending on datatype), "unknown value", and "no value", accessible by clicking the icon to the left of the input box. I propose that a fourth setting be added, indicating that while the statement needs a value, the editor editing does not know the value, and the statement needs filling in. This could be helpful in a number of situations, such as where leaving out a statement or qualifier would be potentially misleading (for example, a statement requires an "end date", but the editor doesn't know what the end date is, but doesn't want to mislead the reader into thinking that the statement is correct until present day), or where a main statement is necessary to add valuable qualifier information. The setting "unknown value" can't be used in these situations, as that implies that the value is generally unknown, not just to the particular editor. Thoughts? --Yair rand (talk) 01:32, 2 July 2013 (UTC)

Make sense to me.--Ymblanter (talk) 06:02, 2 July 2013 (UTC)
The simplest solution I see would be the creation of an item meaning "dont know please help" (and perhaps in the longer term, a special value for that). --Zolo (talk) 08:08, 2 July 2013 (UTC)
A simple item wouldn't work for non-item datatypes. --Yair rand (talk) 08:09, 2 July 2013 (UTC)
I support the original proposal. It can definitely have benefits. TCN7JM 08:10, 2 July 2013 (UTC)
(Edit conflict) I do not agree. This should not be about what a particular editor knows, and I see no point in trying to distinguish what is "generally unknown" and what is unknown by the source for a claim. (BTW you can see how often "unknown value" (somevalue) and "no value" are used in my statement statistics.) Byrial (talk) 08:11, 2 July 2013 (UTC)
Yes sorry, I realized that my comment was all-round stupid after saving... A new special value may make sense, but I'd like to see some usecases, per Byrial's concern. By the way, I think the layout of special values would needs to be re-thought as it seems to confuse some users. --Zolo (talk) 08:16, 2 July 2013 (UTC)

Getting a subset of claims for an entity

The props=claims API query retrieves ALL the claims stored for an entity.

Is there an API query that retrieves only a subset of the claims? E.g., only Date of Birth and Place of Birth for a Person entity? Claudius972 (talk) 23:10, 1 July 2013 (UTC)

AFAIK wbgetentities will not go any further than that. You could use ?action=wbgetclaims&entity=q42 and get the same result, but you can also use &property= (seems this isn't working? I'll file a bug) or &claim= (the GUID) with this.  Hazard-SJ  ✈  01:46, 2 July 2013 (UTC)
Thanks! From the API documentation it indeed seems that claim= or property= should work, but unfortunately they don't. Claudius972 (talk) 13:46, 2 July 2013 (UTC)
The claim parameter worked when I tested it, but it's not the best way to get the required results IMO. Also, bugzilla:50061.  Hazard-SJ  ✈  01:28, 3 July 2013 (UTC)

Search by sitelink when adding statements

Sorry if this has been discussed before, but you know how it's possible to search by sitelink in the search bar? Well, it would sure be nice if something similar was possible when adding statements to items. I can't tell you how many times I've tried to add a city item to a statement only to find that the name of the city without the state is in the label and there's no description, making me have to open a new tab and search by sitelink on that tab to find the item I'm looking for. Any suggestions? If this has been discussed before, can somebody point me to that discussion? Thanks. TCN7JM 08:43, 2 July 2013 (UTC)

Gadget SitelinkCheck adds a link in the left panel to do that. Simply check the corresponding box in your Preferences - LaddΩ chat ;) 23:11, 2 July 2013 (UTC)

Map of all geocoordinates

Hey :)

Denny made a map of the geocoordinates that are currently in Wikidata. You can find it here: https://dl.dropboxusercontent.com/u/172199972/map.png It is being updated daily. Since the script that generates this is operating on the database dumps the data is usually from the day before yesterday. --Lydia Pintscher (WMDE) (talk) 10:16, 26 June 2013 (UTC)

Very nice! -- Edinwiki (talk) 10:17, 26 June 2013 (UTC)
Very nice indeed! ·addshore· talk to me! 10:35, 26 June 2013 (UTC)
Nice to see my work on Minnehaha County, SD, shown! Though from the way Minnesota's lit up, people might think it's part of Minnesota. :\ TCN7JM 10:38, 26 June 2013 (UTC)

And here is a huge version of the file for more details :) https://dl.dropboxusercontent.com/u/172199972/map_huge.png --Lydia Pintscher (WMDE) (talk) 10:44, 26 June 2013 (UTC)

Nice, what about uploading it to Commons daily too ? :). --Zolo (talk) 12:56, 26 June 2013 (UTC)
Sounds like a plan! ·addshore· talk to me! 18:04, 26 June 2013 (UTC)
I'll ask Denny about it. --Lydia Pintscher (WMDE) (talk) 13:02, 28 June 2013 (UTC)
So Denny is fine with releasing this under CC0 and having someone upload it to Commons but he currently doens't have the time to do this himself. --Lydia Pintscher (WMDE) (talk) 10:54, 3 July 2013 (UTC)
I'll try a bot request at Commons. By the way, do I miss something, the "huge" map is 300kb to me ? --Zolo (talk) 08:23, 4 July 2013 (UTC)

What projection are you using? πr2 (t • c) 12:33, 28 June 2013 (UTC)

This is a simple Mercator projection. --Lydia Pintscher (WMDE) (talk) 13:02, 28 June 2013 (UTC)
Are you sure about Mercator projection (Q309372)? Looks imho more like equidistant cylindrical projection (Q1326965).--Spischot (talk) 07:22, 30 June 2013 (UTC)

Namespace statistics for links

It has been on my to-do list for a long time to get the namespace names for all Wikipedias. Now I finally got them so I have made a namespace statistics page which you may find interesting. It gives an overview over which namespaces the sitelinks for each item point to.

Looks good! ·addshore· talk to me! 08:13, 4 July 2013 (UTC)
Thank you. I just updated the page after some bug fixes, so the numbers changed a little. The page now also includes the virtual namespaces. Byrial (talk) 20:42, 4 July 2013 (UTC)

Gujarati language support on android version of google chrome

I used to work on wikidata on desktop but right now i started using android jelly bean phone. I saw that wikidata do not support gujarati language. Gujarati wikipedia can be read. So is it a problem Of unicode support or bug or any Other technical problem? I tried mozilla firefox also; but faced same. If it is a problem of unicode than why Gujarati Wikipedia can be seen? Help me to access Gujarati language as without it whole wikipedia will suffer. Technical help? What should i do? Thanks..--Nizil Shah (talk) 19:29, 4 July 2013 (UTC)

Sourcing requirements for bots

Please see Wikidata:Requests for comment/Sourcing requirements for bots. Pichpich (talk) 19:39, 4 July 2013 (UTC)

Sourcing on wikidata

I am trying to understand what sourcing means on Wikidata. When I go to an item, say Magnoliaceae, it says, under sources, that the taxon name has been "imported from Spanish Wikipedia." But the Spanish Wikipedia article does not cite a source for the taxon name. If the only requirement is that it be tied to another Wikipedia article, not actually sourced to something outside of Wikipedia, then this can be done by bots tying every statement randomly to any Wikipedia.

To me, it seems that sources would be citations to the literature outside of Wikipedia.

Can someone explain this to me? --AfadsBad (talk) 21:45, 3 July 2013 (UTC)

Yes, that is possible with the new URL datatype, but sourced data can (in my opinion) still be imported from Wikipedias.--Jakob Scream about the things I've broken 23:04, 3 July 2013 (UTC)
I think Wikidata:Requests for comment/References and sources is a good pointer. There is a consensus that statements should be sourced with some exceptions (common knowledge, things that don't need a reference in Wikipedia, facts evidenced by the item itself). In your example, the taxon name doesn't need a source and the pointer back to the Spanish Wikipedia shouldn't be understood as a source in the traditional sense. There's a recent thread about this issue. Pichpich (talk) 00:28, 4 July 2013 (UTC)
Why wouldn't a taxon name need a source? --AfadsBad (talk) 03:26, 4 July 2013 (UTC)
Why would you want a source for the statement that says "the taxon name of the taxon Magnoliaceae is Magnoliaceae"? Pichpich (talk) 03:50, 4 July 2013 (UTC)
The taxon name of the Asterids is also Asteranae. This is common in angiosperm taxonomy, and the taxon name has to be attached to an authority unless you are using the higher unranked APG taxa, and even then you need to know which APG. Taxa are defined by their sources; without them you can have the same name apply to a clade (or even afined in different ways. If that is the information Wikidata is giving for everything that "the name of this is the name of this," then you don't need sources for anything, but that is not what Wikidata appears to be, and taxa are defined by their literature, not in a vacuum of unattached proclamations. --AfadsBad (talk) 04:26, 4 July 2013 (UTC)
I stand corrected. I didn't realize that the taxon name can be non-obvious in some cases. These should be sourced properly and they may not be at the moment. This needs to be fixed and that's about all I can say. Pichpich (talk) 05:13, 4 July 2013 (UTC)
"imported from Spanish Wikipedia" means nothing more than this claim is not sourced yet. However, to source a claim, you need to know what the item is about. An empty item "Q56688643" has no information. Therefore, it makes sense, to import basic statements from wikipedias, to see the concept, the item describes. In your case, the plant family Magnoliaceae. As many interwiki links are not correct, as for a fictive example, the English wikipedia article Magnoliaceae is linked to German wikipedia article Magnoliales, these basic claims are enough to a) clean up the interwiki mess and b) later on can be used for "scientific article x says Magnoliales is parent taxon of Magnoliaceae", as you now find both items due to the existing basic claims. Thus, a valuable referenced claim "Q120228 Property:P171 Q27187" citing it with article x can be added. Currently, we're still mainly in the phase of cleaning up items, adding valuable citations is starting. See for example most genus to order-level items of squamata, like Viperidae (Q163656) or items in the order odonata, like Q232693. If you want to help and have sources for Magnoliaceae, help is more than welcome! See Wikidata:Taxonomy task force  — Felix Reimann (talk) 07:27, 4 July 2013 (UTC)
is not intuitive in any way, that this recently added source should tell someone that this clade is unsourced. Do I then follow the declaration of unsourced, with a source, so it reads both unsourced and sourced, or do I replace the declaration of unsourced with a source? --AfadsBad (talk) 14:01, 4 July 2013 (UTC)
After you added a better source (with Property:P248), you can remove it. It should only help to find errors.  — Felix Reimann (talk) 14:34, 4 July 2013 (UTC)
The sourcing policy is given in Help:Sources. And the property "imported from" is not a recognized property for sourcing. Snipre (talk) 15:30, 4 July 2013 (UTC)
Then can we stop bots from adding this, and how? --AfadsBad (talk) 22:25, 4 July 2013 (UTC)
There hasn't been a formal discussion on this although many people have suggested that these "imported from Wikipedia" sources are not a good solution for the future. But my feeling is that there is currently no consensus on what to do with them (keep them, remove them entirely, keep them in some other form that makes the distinction between origin of the imported statement and reliable source) so I think they will stay in the short term. I also think it's hard to resolve that issue before we decide the sort of sourcing requirements we place on bots that add statements (see the current request for comment on the subject). Pichpich (talk) 23:29, 4 July 2013 (UTC)
I would like to source the Wikidata items as I source the same items in en.Wikipedia, fr.Wikipedia, etc., as it seems easy to add the source both places. However, I see no point in adding real sources while this is unresolved, as "imported from Italian Wikipedia" is not a source. Thanks, everyone, for the input and help. --AfadsBad (talk) 01:51, 5 July 2013 (UTC)
Could you give a concrete example what you want to source how? Is this perhaps only an interface problem? It is always possible to add additional sources to a claim. Thus, "imported from" sources should never prevent you from adding additional, valuable references. See for example the scientific name of Q662672 which is sourced by a paper and a taxonomic database. Or the taxonomic rank and the scientific name of Q662672, which have some "imported from" references but also a "citable" reference to a compiled list of valid species. If for example fr.wikipedia would import that claim, it could ignore all "imported from" sources and show only references which are valid according to Help:Sources.  — Felix Reimann (talk) 08:04, 5 July 2013 (UTC)
Italian/whatever Wikipedia is not a citable source for a taxon authority, not even on most Wikipedias. Every page that has "imported from pl/en/it/fr.wiki," also already contains an interlanguage link to the item at pl/en/it/fr.wiki, so saying it is imported from that Wikipedia repeats information and adds nothing. A database that repeats information for no purpose is inefficient. If "imported from another Wikipedia," is useful and necessary, simply create a bot that will add this repetition from every interlanguage link already existing--you could fill wikidata to the brim!
And, then, make something else that means this is a citation to an authoritive work on the topic, not the same thing that means "we copied the interlanguage wiki from below and said it is imported above."
Yes, your example is generally how a source for a taxon name should be done in Wikidata, giving the primary source plus a secondary or tertiary source (although better in reverse order), or just the secondary or tertiary source. See my sourcing of taxon authorities for Angiosperm families on en.Wikipedia; as I am finishing and checking my work and adding the secondary sources to the families, I would like to add the same sources to Wikidata. But, if I add these now, while Wikidata is still deciding that sourcing means multiple things, or a single thing, it is a waste of my time.
I will watch wikidata, and when editors here figure out that "imported from en.wiki" is already included in the interlanguage links, or means something different, or means just that and something new should be for sourcing from literature, I will start adding the citations. Wikidata seems like a good idea, and I am willing to contribute, but I have limited time, and I would rather spend it adding useful contributions. --AfadsBad (talk) 13:23, 5 July 2013 (UTC)

sources as Wikidata

I've been told several times by various people that Wikidata will eventually take care of citations to sources on Wikipedia. Instead of writing out sources in text, Wikidata will eventually be one great big bibliographic database. A source will be a single entry in Wikidata, no matter how many times it's cited on Wikipedia. I gather this project is still in the future, but is there any idea when it might get started? I'd like to help. -- Kosboot (talk) 12:38, 5 July 2013 (UTC)

I think the only technical blocker for that is that the only Wikipedia can currently only access data from the linked Wikidata item, ie, in en:Barack Obama we can acess data stored in Barack Obama (Q76) but not those in Obama: From Promise to Power (Q7074604). It seems that it is currently planned for October (mw:Roadmap#Wikidata deployment). Note however, that there does not seem to be any plan about that from the developers to support this functionality. This is not striclty required, but as it would imply hundreds of calls to Wikidata per article, there are also performance conserns that will have to be addressed. In any case, you may be interested in Wikidata:Requests for comment/Source items and supporting Wikipedia sources.--Zolo (talk) 13:59, 5 July 2013 (UTC)
Thanks! -- Kosboot (talk) 15:19, 5 July 2013 (UTC)

Descriptions of templates

Hello I have a question: en:Template:Good article/doc, de:Vorlage:Lesenswert/Doku, pl:Szablon:Dobry Artykuł/opis - should link to each other on Wikidata? Should I create entry for every "description"? PMG (talk) 20:08, 4 July 2013 (UTC)

These pages, per WD:N, are not appropriate for Wikidata. --Izno (talk) 17:48, 6 July 2013 (UTC)

Time Datatype; before / after

The datatype page mentions that the time dataype has values for before and after the point in time specified, for when the time is not known precisely. Are those values not usable/implemented yet, or are these just not available from the time input tool (or am I too stupid to use it)? Hobofan (talk) 21:24, 5 July 2013 (UTC)

These features are implemented in the database but the UI is not ready. It is like for the rank parameter. See here. Snipre (talk) 08:32, 6 July 2013 (UTC)
Ranking is already implemented at the backend system? --Nightwish62 (talk) 15:12, 6 July 2013 (UTC)
Before/after is uncertainty, but I'm not sure they will be used as that… Jeblad (talk) 18:32, 6 July 2013 (UTC)

Storuman (sjö)

There is an item http://www.wikidata.org/wiki/Q11894507 (fi:Storuman (järvi)) that does not allow me to add the correct interwiki fi:Storuman (järvi) into the item http://www.wikidata.org/wiki/Q465037 that contains the rest of the interwikies of the same subject. There also seems to be some systematic bug, when bots create such orphan items which in its turn leads to the result that the interwiki cannot be added to the right place. Perhaps there would be a template that could be added to the useless orphan page, but instead of trying to find it I will now only write here.--Urjanhai (talk) 17:12, 6 July 2013 (UTC)

Those have been merged now. --Stryn (talk) 17:16, 6 July 2013 (UTC)
Thanks. --Urjanhai (talk) 17:21, 6 July 2013 (UTC)

Not counting "imported from" as a source

 
Proposal for imported statements

Hi! Would it be possible that when imported from Wikimedia project (P143) is placed in the source section of the statement, it doesn't count for the total number of sources of that statement and that instead a tag "imported" is shown next to the sources count? I have made a little mockup (see right).--Micru (talk) 14:32, 6 July 2013 (UTC)

Imported from is still a source, regardless of where the information came from. --Izno (talk) 17:47, 6 July 2013 (UTC)
Nice idea, but I think that when we import something it is in fact used as our source. The only time where there are real differences are when we reuse some external provided sources as our own. Jeblad (talk) 18:28, 6 July 2013 (UTC)
If you consider "imported from" a source (which is not, it is just a data provenance indicator, quite different from "stated in" or other properties required for sourcing statements as per Help:Sources), I wonder how are we going to break the vicious circle of using Wikidata statements imported from Wikipedia in Wikipedia (as in "English Wikipedia states X, according to English Wikipedia").--Micru (talk) 20:24, 6 July 2013 (UTC)
As soon as the imported data comes from an external source all data that states Wikipedia as source should be deprecated. Jeblad (talk) 20:30, 6 July 2013 (UTC)
And until that happens, how would you indicate that a statement needs an external source? --Micru (talk) 21:56, 6 July 2013 (UTC)
The statement can be sourced just like any other statement, by saying the source is a wikipedia project. Claiming that a wikipedia is not a good enough source is another problem, but that is solved simply by checking the source which says it is a wikipedia project. The model is more than sufficient to solve this problem. Jeblad (talk) 22:19, 6 July 2013 (UTC)
And when it is used in Wikipedia will it appear as the source of this statement in this wikipedia is this same wikipedia project? That is a circular reference, which gives a terrible image, and it won't help in the mission of Wikidata becoming a storage of facts that can be used in any Wikipedia, specially if most statements are sourced this way (as now) and there is no clear visual distinction for users.--Micru (talk) 16:20, 7 July 2013 (UTC)
Sorry but I can't see the problem you try to describe. We source our value, how the clients chose to reuse or not reuse our values is not the problem in this case. Our value is not sourced from some other external site, and it is not unsourced, it comes from a specific Wikipedia page. If we want to say that Wikipedia pages are not good sources, then that is another question, and if we don't want some specific clients not to use the value it is still another question, but the value is sourced. Jeblad (talk) 16:54, 7 July 2013 (UTC)
To me it seems you are trying to confliate "source" with "reliable source", when that is not the connotation. "Where we got some piece of information" is the source, regardless of whether we should have gotten it from location A or location B. Fixing the UI doesn't actually fix the problem you are trying to solve; it is obvious to everyone that this shouldn't be the case, but until someone, say, writes a bot to replace sourcing for e.g. the taxonomic tree we have implemented, we're kind of SOL. --Izno (talk) 17:14, 7 July 2013 (UTC)
Thanks for your clarification, Izno. I hope that when sources can be ranked and not reliable ones can be flagged as such, it will become less of an issue.--Micru (talk) 18:33, 7 July 2013 (UTC)

String + Lua = anything?

Being impatient for when badges of featured and good articles will appear, I have thought about immediately installable crutch like: let's create a String-typed field, fill it with content like en:fa;ru:ga;es:a;ce:stub;de:rfd, and in each project write a Lua module which will hang all the required stars according to this field from a single template. On Wikidata a user script can hang stars according to this, so it would be easier to complete a page by its iwiki from the best sources. What do you, good people, think about this case specially and appropriacy of such crutchy method generally? Ignatus (talk) 17:44, 6 July 2013 (UTC)

This was discussed more than a year ago. I didn't like it then and I don't like it now. The reason is that badges are not properties for the entity, it is properties for the pages pointed to by the sitelinks. Anyhow if you want to do it, then the correct way is to have properties like "featured article", and they should then take a single language code. You should then add a statement for each page with that language code that has the specific badge. Well, slightly more correct, you should use URLs and not language codes. Use of language codes creates an assumption that badges can be held only by established sitelinks which is not quite correct. Jeblad (talk) 18:23, 6 July 2013 (UTC)
It could be useful to mark links to redirects, once they have been implemented. Littledogboy (talk) 13:55, 7 July 2013 (UTC)

Wikidata:Requests for comment/Defining inactivity

This is a RFC defining inactivity for the administrator flag. Go comment! --Rschen7754 23:56, 6 July 2013 (UTC)

Could someone please file this request in BugZilla?

Tracked in Bugzilla
Bug 50893

I made a suggestion on en:MediaWiki talk:Common.css#Appearance of Wikidata edits in the watchlist, where I was told to submit the request to BugZilla. Unfortunately, I do not have any experience in bugzilla.
If anyone thinks the suggestion should be modified, please share your opinion. --Leyo 16:22, 7 July 2013 (UTC)

More than one interwiki per language ?

Would it be possible to allow the addition of more than one interwiki link in a given language? The only reason I see for not having this already is that the majority of Wikipedias have only one article per subject, but what if a Wikipedia allows to have more than one article for the same subject? Amqui (talk) 18:05, 11 June 2013 (UTC)

Huh? Why would they want to have more than one article about one subject? Are you thinking of any specific Wikipedia, or is the question purely hypothetical? Byrial (talk) 19:03, 11 June 2013 (UTC)
There are situations when different Wikipedias have differents sets of articles (many of the situations mention, e.g., here are of this category). But allowing more than one interwiki link will result in a mess. You talk about situations with one article - two articles. But there can be situations with two articles in one language correspond to three articles in another language (and one article in the third language). It would be simply unbearable. --Michgrig (talk) 19:27, 11 June 2013 (UTC)
The articles in different Wikipedias may have all variations of overlaping subjects, and that has been discussed numerous times. But that is different than one Wikipedia allowing two articles about the same subject. Byrial (talk) 19:40, 11 June 2013 (UTC)
I thought that 'no forking' is one of the basic rules in every Wikipedia. So I didn't even think about this possibility :) Am I not right? --Michgrig (talk) 19:47, 11 June 2013 (UTC)
I call this the Bonnie and Clyde (Q219937) problem. Some wikipedias have an article on Bonnie and Clyde while others have separate articles on Bonnie Parker (Q2319886) and Clyde Barrow (Q3320282). We have agreed that the devs will amend the software so we can link to redirect pages as well as linking to articles. This should, in most cases, solve this problem. Filceolaire (talk) 19:55, 11 June 2013 (UTC)
There is a property for this case, but some people want to delete it.JAn Dudík (talk) 20:09, 11 June 2013 (UTC)
It's reciprocal and therefore redundant, no information would be lost. —★PοωερZtalk 20:25, 11 June 2013 (UTC)
The question isn't hypothetical. Some Wikipedias in small languages where the language isn't as codified as bigger languages like English may have the exact same subject in different dialects, or even only for languages that use different scripts, they may have the same subject written in each script. An example of that is w:cr:ᒥᒋᓯᐤ and w:cr:Mikisiw ka wapictikwanetc, both are about the bald eagle. Amqui (talk) 21:20, 12 June 2013 (UTC)
Also similar to the problem of Incubator. --MF-W 21:26, 12 June 2013 (UTC)
Maybe a solution would be to allow to use more than one "language name" per project. It would work for the Incubator problem as well as Wikipedias with more than one dialect or different scripts. We would use different "language names", but the interwiki links themselves would point to the same project. Using the above example, the interwiki table for "bald eagle" could contain "ᒥᒋᓯᐤ" for "Iyiyiw-Ayimuwin (syllabics)" and "Mikisiw ka wapictikwanetc" for "Atikamekw", but both would point to crwiki. It wasn't really doable with the previous way to handle interwikis, but with Wikidata I think it is implementable. Amqui (talk) 19:36, 13 June 2013 (UTC)

Note sure why this discussion has been archived since no solution had been found... Amqui (talk) 03:28, 21 June 2013 (UTC)

I can also think of the same subject with the article written for different publics (for example in math, article for mathematician and for public). TomT0m (talk) 09:28, 21 June 2013 (UTC)

An earlier discussion of the problem: Wikidata talk:Interwiki conflicts#Sibling_conflicts. --AVRS (talk) 10:02, 21 June 2013 (UTC)
To some degree links to language variants can solve this, but it would need further thoughts because it has some nasty implications. That is duplicate linkage can be difficult to avoid, and then all templates in the clients must handle multiple items. Which basically makes the complexity explode due to a fringe case. It is also possible to link to especially marked redirects, the Bonnie and Clyde problem, but to link to redirects in general would create a mess. Still note that the Bonnie and Clyde problem is not the same as the article fork due to language variants. To make some of the lookup work properly it is necessary to identify a single article on the client, and without a single unique title this will fail. And yes, it has been discussed several times in the past. Jeblad (talk) 10:25, 21 June 2013 (UTC)
I'm not sure what you mean by "client"? And what is "lookup work" you are talking about and why would we absolutely need a single article on the "client"? Amqui (talk) 21:48, 29 June 2013 (UTC)

I really don't understand the principle behind archiving non resolved topics on the project chat... Amqui (talk) 21:41, 29 June 2013 (UTC)

One: It's automatic. Two: It's probably not going to be changed. Three: It's been discussed to death here and elsewhere. --Izno (talk) 21:49, 29 June 2013 (UTC)
I'm not talking about the Bonnie and Clyde problem, but about Wikipedias that have more than one article about the same subject due to the use of different scripts and/or different dialects which is a totally different issue in my opinion, and I haven't seen prior discussions about that. I already proposed a possible solution (i.e. allowing different "language name" entry in the interwiki link to point to the same project, which would also work for the Incubator). But, if the solution from the part of Wikidata is to "change nothing", how local Wikipedia go about choosing what article to link, for example why the interwiki link for "bald eagle" for "crwiki" would be the one in syllabics and not the one in latin alphabet (or vice versa)? Amqui (talk) 21:52, 29 June 2013 (UTC)
This is getting archived because nobody feels that it's a sufficiently common problem to warrant spending a lot of resources developing a solution for it. And as Jeblad noted, it's not even clear that we can find a solution that solves more problems than it creates. I'm sure the Cree Wikipedia can work around this problem like every Wikipedia works around various annoying limitations of the software. (By the way, why are these two articles of the Cree Wikipedia not linked to one another? Also, regardless of the Wikidata issue, if it's just a question of different scripts, having the same article in both scripts on the same page might be a more practical solution and a more educational one too.) Pichpich (talk) 07:39, 30 June 2013 (UTC)
To be simple it is not a wikidata problem: it is a Cree Wikipedia problem which allows different scripts this leading to duplicated articles. The Cree Wikipedia has to define clearly which is the script to use and if some persons want to use another script better create a new wikipedia. Snipre (talk) 08:27, 30 June 2013 (UTC)
The Cree Wikipedia is not the only one using different scripts and far from the only language to use different scripts. Current language policies of Wikimedia only allow the creation of new project in a language having an ISO code and in most cases there isn't different ISO codes for a same language in different scripts. As per the Language Proposal Policy, "the language must be sufficiently unique that it could not coexist on a more general wiki. In most cases, this excludes regional dialects and different written forms of the same language.", which refrain the creation of separate Wikipedias, but doesn't refrain of course individual Wikipedias from using different scripts/dialects within their project if they so decide, and they should still be supported by Wikidata for interwikis in my opinion since they are following Wikimedia general policies. So I won't discuss here about the "it is a Cree Wikipedia problem which allows different scripts" comment since this decision is only to the concerned community to make, and it wouldn't make sense to separate a same-language community into two projects only based on the scripts used, especially when this community is small. Anyway, the creation of new Cree Wikipedias wouldn't solve this issue, since they would go in the Incubator which has the exact same issue, i.e. it needs the possibility of having more than one interwiki for the same project to include the different Wikipedias it encompasses. Amqui (talk) 02:59, 1 July 2013 (UTC)

I agree with Amqui. This should be addressed on Wikidata somehow. Other wikis with varying forms of the multiple-dialects problem include the Serbian and Serbo-Croatian projects, nrmwiki, angwiki (until recently), some Italian dialects like napwiki & emlwiki (although they tend to have all the dialects in one page, avoiding part of the problem), and to a lesser extend alswiki. I could find more. Note that the problem also extends to Wikidata: which dialect do we use in descriptions? πr2 (t • c) 17:38, 2 July 2013 (UTC)

Since you mention Serbian Wikipedia, this seems to be a paragon of how this issue can be handled without making mess of Wikidata – switchable transcription there, dual labels here (sr-ec/sr-el). Littledogboy (talk) 19:55, 3 July 2013 (UTC)
Switchable transcriptions are not feasible for all languages, but this is of course the ideal solution when feasible. Amqui (talk) 20:20, 3 July 2013 (UTC)
Also having different scripts/dialects on the same page may not be desirable for all projects, and this decision shoudldn't be imposed to Wikipedias if having separate articles works better for their needs. Amqui (talk) 16:08, 5 July 2013 (UTC)
This is one of the areas where the clients (Wikipedias) must adapt if they want to use data from the repo (Wikidata). Its a matter of choice whether we want to have high security against faulty linkage or whether we accept low security and a lot of faulty linkage. Accepting more than one sitelink per language version of Wikipedia will lead to a lot of faulty linkage. Jeblad (talk) 18:46, 6 July 2013 (UTC)
Not if we still continue to only authorize one sitelink per language but authorizing more than one sitelink per project by redefining language here by "a specific language in a specific script/dialect" for the languages that use more than one script/dialect. Like that it changes nothing to the "security" you mentioned; nobody here propose to allow to add multiple sitelinks to all Wikipedias entries on Wikidata. Can you explain how having one entry for Language X in Script A and one entry for Language X in Script B pointing towards the same project will result in more faulty linkage? The intent here is not to allow more than one link/entry per defined language in Wikidata, just to add more "languages-and-scripts" combinations and allowing more than one language to point towards the same project. I can see your point that allowing an indefinite (or even a definite) number of sitelinks for a Wikipedia could lead to faulty linkage, but I don't see how having more than one specific defined "language" entries for a given project would lead to more faulty linkage than it is the case with the actual system. For the example of crwiki, one wouldn't just add two or three articles to crwiki on Wikidata, instead one would add each article on crwiki in a defined script on Wikidata: Canadian Syllabics or latin alphabet for example; only one article per "defined languages", but both pointing to crwiki.
Also to answer on your comment "This is one of the areas where the clients (Wikipedias) must adapt if they want to use data from the repo (Wikidata)." This is not only the problem of some Wikipedias (i.e. the ones who use more than one scripts on different articles for a same subject), but all Wikipedias. Are you suggesting Wikipedias having more than one script should opt-out of Wikidata and not having their interwikis added to all other Wikipedias? The problem isn't even on the client Wikipedias, but on all other Wikipedias in fact where only one article in one of the scripts is linked in the interwiki list instead of every article for the same subject, making it a Wikidata issue, not a "client" problem. Amqui (talk) 23:44, 7 July 2013 (UTC)

In the future, there will be more problems. The langcom language policy as recently adopted has the consequence that developments of simple versions of a language would be on the wiki of the full language. This is also the case with oldwikisource:, betawikiversity:, and incubator:, where many languages are on the same wiki. Ebe123 (talk) 00:17, 8 July 2013 (UTC)

property proposal discussion edits

Just some figures about how many times the property proposal discussion was edited in the last three month:

(June, May, April)

  • Generic: 85 / 248 / 227
  • Creative Work: 125 / 64 / 276
  • Person: 82 / 259 / 167
  • Event: 17 / 39 / 26
  • Place: 136 / 260 / 189

I've a feeling that many old proposals don't progress and that even new proposals get hardly any attention anymore. I don't know the exact reason, but it could be the fact that peoples are getting tired of every time the same discussion, like: should we use "type of xxx"-properties or just the instance-of-property, or, should we create dedicated properties or us generic properties together with qualifiers.

Another report I'd like to have is, top 5 contributors in adding statements (without label/item naming) and the number of their edits. Is it possible to retrieve this data? I don't know, but I think there are very less people who are contributing statements manually (without any help of bots). --Nightwish62 (talk) 21:07, 1 July 2013 (UTC)

I think that working property by property is the wrong granularity. That's why I launched Help:Modeling, to complete discussions around task forces and discuss a whole model for a domain of application. We could then vote for a whole Wikidata domain model, basically a set of properties, and create all at wonce the needed properties. It would also help to have a better view on what property already exists, what works and so on. The idea has been saluted and encouraged by one or two contributors but we probably need to develop it together (and find other way of working) to become productives in that area. TomT0m (talk) 10:35, 2 July 2013 (UTC)
@TomT0m Finally what you propose with your Help:Modeling page is just a copy-paste of what was the Wikidata:Infoboxes task force in an extended way: list properties needed to define an object according to its class. Better stop here with this new page in order to avoid to disperse the work on different pages. Snipre (talk) 12:03, 2 July 2013 (UTC)
I index content of some infoboxes task forces in my page. I think Infoboxes task force is misleading because of the name : we do not talk about infoboxes at all, no more than we prepare migration to infoboxes ... . Plus its base on GND is kind of disturbing to me. My approach is larger, and we really need that to avoid property by property discussion and mutualisation of the work to address the problem adressed by Nightwish. Nobody touches the infobox task force page anymore, in my opinion it is a sign that we need somthing new and a fresh start. TomT0m (talk) 16:35, 2 July 2013 (UTC)
The current arrangement with separate pages for agreed properties, pending properties and proposed properties is clumsy. How do you find the right page? Dividing the proposed properties between 5 categories means each page is very long. I think this could be better with more pages each approximately corresponding to an infobox. As properties are agreed the property discussion could be archived but the property info should be kept on the page so the page has a record of all associated properties. (I also believe the GND Main Types should be replaced by a much larger number of types, corresponding to these pages and the infoboxes.) This needs an RFC. 86.6.107.229 18:55, 3 July 2013 (UTC)
There's an ongoing RFC that's very related to your concerns: Wikidata:Requests_for_comment/Primary_sorting_property. I think your suggestion to have types corresponding to infoboxes would be easiest to achieve by not having any "primary sorting property" (also known as a "main type property") whatsoever, and using instance of (P31) and subclass of (P279) to build more robust type hierarchies. Emw (talk) 20:19, 7 July 2013 (UTC)

consists of -> has part

There's a proposal to change the label of P527 from "consists of" to "has part" at Property_talk:P527#consists_of_-.3E_has_part. Input welcome! Emw (talk) 04:09, 8 July 2013 (UTC)

Wikivoyage

Heya :)

I've just informed Wikivoyage about this and wanted to give you a heads-up here as well. Wikivoyage will get language links via Wikidata starting July 22nd. There is Wikidata:Wikivoyage migration for coordination.

Cheers --Lydia Pintscher (WMDE) (talk) 15:02, 3 July 2013 (UTC)

Will the Wikivoyage links go in separate pages or the same pages as Wikipedia items? --Jakob Scream about the things I've broken 16:09, 3 July 2013 (UTC)
I think that the Wikivoyage links will go in the same Wikidata items as Wikipedia links in order to avoid duplication of content (coordinates...) and to allow a possible Wikidata based inteproject linking system in the future. Tpt (talk) 19:04, 3 July 2013 (UTC)
Yes. What Tpt said. --Lydia Pintscher (WMDE) (talk) 19:46, 3 July 2013 (UTC)
Why wikivoyage and not Commons? There is much more demand for that. Multichill (talk) 23:18, 4 July 2013 (UTC)
Because Wikivoyage is more similar to Wikipedia in many ways and therefore an easier next step. Other projects will follow. --Lydia Pintscher (WMDE) (talk) 08:48, 5 July 2013 (UTC)
  Strong support   --Ricordisamoa 09:09, 5 July 2013 (UTC)
Is there a mockup somewhere for how pages will look? We're only two weeks from deployment yet we've got nothing of how the pages will look. --Izno (talk) 17:55, 6 July 2013 (UTC)
There will be another table below the one that we have already for Wikipedia that will hold the links for Wikivoyage. There's really not much more to it. --Lydia Pintscher (WMDE) (talk) 18:01, 6 July 2013 (UTC)
Are item pages going to start having TOCs? They are going to be rather unwieldy if that's how the UI is going to be for n-number of projects... --Izno (talk) 20:51, 7 July 2013 (UTC)
Not yet unfortunately. It's being worked on however. I'd also assume that most items will not have links to more than one or two projects. --Lydia Pintscher (WMDE) (talk) 09:19, 8 July 2013 (UTC)

Very rough and tentative timeline for the next month of development

Hey :)

Denny published a very rough and tentative timeline for the next month of development: mw:Roadmap#Wikidata deployment I hope this will give you some idea of what is there to come. Please keep in mind though that this obviously might change if we run into unforseen issues. Please let me know if you have any questions. --Lydia Pintscher (WMDE) (talk) 12:13, 5 July 2013 (UTC)

I was wondering if there are plans to centralize page view statistics? --Tobias1984 (talk) 18:47, 7 July 2013 (UTC)
Not from our side, no. --Lydia Pintscher (WMDE) (talk) 19:39, 7 July 2013 (UTC)
Could it go into the suggestion box? There would be some interest from Wikiproject Medicine to have better global stats (not just English Wiki: en:Wikipedia:WikiProject_Medicine/Popular_pages). --Tobias1984 (talk) 10:50, 8 July 2013 (UTC)
I can see how it'd be very useful but I don't think Wikidata is the right spot for it. --Lydia Pintscher (WMDE) (talk) 10:55, 8 July 2013 (UTC)
Analytics (lightning Kraken demo) - Andrew Otto (remote) / Evan Rosen - 3 minutes. WMF Metrics and activities meetings/2012-12-06
There is a project for better page view statistics, with the ominous name "Kraken" (Datenkraken?). See:
  • meta:Glossary#K, Kraken: the upcoming data services platform that the Wikimedia Foundation's Analytics team is working on. It will allow interested persons to query data to answer their questions about Wikimedia projects and users.
  • mw:Analytics/Kraken and mw:Analytics/Kraken/Blurbs
  • commons:File:Report_on_requirements_for_usage_and_reuse_statistics_for_GLAM_content.pdf (June 2013) "there is clearly a need for GLAM-related statistics, for research purposes, but mainly to enable GLAMs to use Wikimedia Projects as a mature distribution channel for their collections. (...) The next steps are up to the analytics team of the Wikimedia Foundation to start gathering the information required (using Kraken) and work on a page (using Limn) to display that information. The GLAM toolset project will continually and regularly liaise with the Wikimedia Foundation to ensure this development is prioritised".
I am quite worried about this kraken-data. When german Wikipedia prominently linked to page view statistics on every Wikipedia page, this resulted in SEO spammers using this tool to determin popular target articles for spamming their links on WP. Apparently now the GLAM community (composed of well-funded institutions with PR departments) is pushing for these analytics to be built by WMF (funded by donations for Wikipedia). Before that, the ISP partners for Wikipedia Zero (and WMF marketing) were asking for special page views statistics, including Saudi Telecom ("No, we never talked about censorship"). And while the toolserver had a privacy policy, that is not the case with kraken, afaik. Pandora box, anyone? --Atlasowa (talk) 13:02, 8 July 2013 (UTC)
Thank you for that information. I was not aware of that project. Even rough statistics might help with e.g. prioritizing which medicine topics should be translated (Wikipedia:WikiProject_Medicine/Translation_task_force). --Tobias1984 (talk) 16:15, 8 July 2013 (UTC)
Looking at the Wikidata road map, i find unexplained notes like this:
  • September: Simple queries (one property with one value), Quantity datatype
  • October: Range queries, arbitrary item access, statements with ranks
  • November: Visualisations of results
  • Volunteer contributed deployments: August: GLAM image uploader(?)
No idea what that is supposed to say. Why don't you link in the road map to the relevant discussions that explain these bullet points? And I see nothing about references and sources for Wikidata, why? --Atlasowa (talk) 13:02, 8 July 2013 (UTC)

Books about semantic web (thats'r us)

Some time ago I made a page for books and other sources with focus on Wikidata-like methods, that is semantic web in general and linked data in particular. Its only a small fraction of whats available, but one of the books are interesting: Linked Data: Evolving the Web into a Global Data Space [1] by Tom Heath and Christian Bizer. This book is online and it is free. I think it is a good read for everybody involved in Wikidata. If that book isn't enough, another one is highly recomended on the net: A Semantic Web Primer ISBN 978-0-262-01828-9 by Grigoris Antoniou and Frank von Harmelen. This book is somewhat more technical and perhaps not for everyone. If you have good books on the topic or other sources then feel free to add them to the page! Jeblad (talk) 17:23, 7 July 2013 (UTC)

This is a great idea. I added a few books that have helped me begin to wrap my head around Semantic Web and ontology languages, etc. I also added an 'Articles' section for relevant articles, like the article that introduced the notion of the Semantic Web. Emw (talk) 21:24, 7 July 2013 (UTC)
Your books are heavier than mine! ;) Jeblad (talk) 04:29, 8 July 2013 (UTC)
Thanks for the book suggestions. I will have to read one of those. --Tobias1984 (talk) 16:57, 8 July 2013 (UTC)

Indexing of Items by search engines

I think wikidata item pages are not indexed by search engines. Is there any specific reason for that? --Vssun (talk) 09:15, 8 July 2013 (UTC)

I think google or other search engine may be indexing wikidata but they try not to display them in their results since it is not applicable for user consumption. A search engine would rather display a Wikipedia in their search result. --Napoleon.tan (talk) 10:41, 8 July 2013 (UTC)
By the way I saw Property namespaced-wikidata page are revealed in google search result but entity-namespace do not. I think they intentionally filter entity pages and would rather use it in their knowledge graph. --Napoleon.tan (talk) 10:45, 8 July 2013 (UTC)--Napoleon.tan (talk) 10:45, 8 July 2013 (UTC)
If Property-namespace is indexed it could be an indication that robots.txt is wrong. Someone should ask Google how we should best do this, they have a team working on Wikimedia-related stuff. Note also that Google was one of those that funded the project. Jeblad (talk) 14:43, 8 July 2013 (UTC)

Let me talk about my interest in this subject.

I am a Malayalam wikipedia contributor. We have some unique pages at ml.wikipeida which are not there at english or any other wikipedias (eg. Punjab Board of Administation, Zahir Dehlavi). I think Wikidata is a good platform to reach such articles for a non-ml user, if such pages are indexed by search engines. --Vssun (talk) 16:11, 8 July 2013 (UTC)

Source as imported from wikipedia

What is the point of bot-based mass adding "imported from: xx Wikipedia" as source for statement (sometime as multiple sources linking to different wikipedias)? This is not covered by Help:Sources and sourcing from another wikipedia is forbidden on almost all wikipedias. I can accept that as temporary solution in cases, when information in statement is really properly sourced in wikipedia tagged as sourced, but i am afraid the bot is not able to determine that. --Jklamo (talk) 14:36, 1 July 2013 (UTC)

Theoretically this is not more authorized. Before the creation of properties and definition of a guideline for sourcing this was accepted as a way to add some data. If you see some bot imports using this sourcing method better bring that in the project chat in order to discuss the case. The main idea is to keep the already imported data a certain time in order to let contributors the possibility to change them and after a certain time to discuss the possible deletion of data sourced by this way. Snipre (talk) 15:59, 1 July 2013 (UTC)
OK, here is the case - item Q57434:
  • property main type
    • 3 March 2013 created and filled by bot
    • 3 March 2013 bot added source "imported from: Swedish Wikipedia"
    • 6 May 2013 another bot added source "imported from: German Wikipedia"
  • property sex
    • 3 March 2013 created and filled by bot
    • 3 March 2013 bot added source "imported from: Swedish Wikipedia"
    • 5 June 2013 another bot added source "imported from: Virtual International Authority File"
    • 30 June 2013 yet another bot added source "imported from: Italian Wikipedia"
  • property VIAF
    • 11 April 2013 created and filled by bot
    • 11 April 2013 bot added source "imported from: English Wikipedia"
    • 6 May 2013 same bot added source "imported from: German Wikipedia"
I can accept adding first (although I think useless) "wiki" source, but i have no idea what is the purpose of multiplying them (most recent case is from 30 June). --Jklamo (talk) 16:43, 1 July 2013 (UTC)

It's nice to know where bots got their info when we want to understand mistakes made in the importation of the data (which is often not the fault of the bot). But to comment on your example specifically, note that the three statements are not statements that require a reference: the fact that Václav Klaus is a person is indisputable, it's common knowledge that he's a man and the only meaningful source for the statement that his VIAF id is 64070163 is the VIAF link itself. I don't know the exact rules on cs.wiki or sk.wiki but I'm almost certain that the sentence "Václav Klaus is a Czech male politician whose VIAF is the one with id 64070163" would not be accompanied by a citation. On the other hand, the statement that he was an ODS member from 1991 to 2009 would most likely require a reference on Wikipedia and should also require a true reference (not simply an "imported from Wikipedia") on Wikidata. Pichpich (talk) 17:51, 1 July 2013 (UTC)

Marking something as imported from XX Wikipedia is a very good indication of how and why some statement is made. It is basically the same as to say "I don't know what is the exact source but I found the value here". That said we did agree on not using Wikipedias that has no connection to a specific area as source for data from that area. I just found a bunch of data imported from Dutch Wikipedia about Norway, and a lot of the data was far off. Not sure what to do with it, manually correcting bot imports of this magnitude isn't something you want to do. Use data from the Norwegian Wikipedias as source for statements about Norway, and Swedish for data about Sweden, etc. Wikipedias that has no connection to the area often has a lot of errors. Jeblad (talk) 17:55, 1 July 2013 (UTC)
My experience is that data on Russia in the English Wikipedia is often better than the one in the Russian Wikipedia.--Ymblanter (talk) 18:28, 1 July 2013 (UTC)
If the statements are the kind that requires a source, then bots shouldn't import them from the nl.wiki, en.wiki, ru.wiki or any other wiki because they're not reliable sources. For non-trivial statements, it's not good enough for a bot to say "this might be complete bullshit but if that's the case then it's en.wiki's fault". Pichpich (talk) 18:52, 1 July 2013 (UTC)
Would it be possible to indicate in another way the data provenance when it is imported from Wikipedia?--Micru (talk) 23:15, 1 July 2013 (UTC)
Jklamo: you are right that 'imported from xx:wikipedia' is not an adequate reference but it is useful for helping us keep track of where stuff has come from. Where we have statements from two different wikipedias then in any cases where these differ we have an indication there is a mistake which needs to be checked. 86.6.107.229 18:21, 3 July 2013 (UTC)
I think there is a misconception of what the source is in these cases. The source is the actual Wikipedia. If you extract the data from the external source Wikipedia used, then your source is what Wikipedia says is their source. If you verify that your extracted value from Wikipedia is the same as someone else extracted from the external source, then you may say your source is the same as Wikipedias external source. You should not say that just because you extracted some value from Wikipedia it is the same as the external source given by Wikipedia. Jeblad (talk) 18:14, 6 July 2013 (UTC)
If you check the source that Wikipedia refers to then you can give that reference as the source for the statement on Wikidata.
If you copy the source info from the Fooish Wikipedia and don't check it then you should include 'imported from Fooish Wikipedia' in the source description on Wikidata. Filceolaire (talk) 02:12, 9 July 2013 (UTC)

Successor / predecessor (P155 P156)

Please discuss in one place, this is just a pointer :) http://www.wikidata.org/wiki/Property_talk:P155#Drop_the_constraint_to_creative_work --Denny (talk) 22:00, 8 July 2013 (UTC)

reciprocal property -> inverse property

The page at Category:Properties_with_reciprocal_constraints lists properties that have reverse relationships between their subject and object: father (P22) and child (P40), for example. This type of relation is supported by OWL, the W3C recommendation for the Semantic Web, as owl:inverseOf. More broadly, writing about the Semantic Web refers to such properties as inverse properties, not reciprocal properties. The idea of an inverse function also seems much more applicable to what "reciprocal properties" do than their current name. What are others' thoughts on changing the way we refer to this type of property from "reciprocal property" to "inverse property"? Emw (talk) 17:02, 6 July 2013 (UTC)

Agree. Jeblad (talk) 18:29, 6 July 2013 (UTC)
  Done--Zolo. The parent cat, Category:Reciprocal properties still need to be fixed. --Zolo (talk) 13:53, 9 July 2013 (UTC)

I cannot add any wikipedia

E. g. I wanted to add de:Gad Ja'akobi to Q612860. While I could easily add a Commons Category or any other data item, the system won't let me enter any wikipedia. If I press "add" and then chose "Deutsch (de)" (or any other language), nothing will happen, that second input box will not open at all. (It used to work quite normal in the past, but suddenly it doesn't.) What can I do? --AndreasPraefcke (talk) 08:49, 9 July 2013 (UTC)

Now, suddenly, it works. This is weird behaviour. --AndreasPraefcke (talk) 08:51, 9 July 2013 (UTC)

RfC Image properties

Very brief RfC about image properties: LINK. --Tobias1984 (talk) 12:56, 9 July 2013 (UTC)

Merging of items with years or other numbers in the page titles

I made a program to find candidates for items to merge by comparing link titles in two languages. The idea is that if a page in language 1 with a number in the title links to a page in language 2 with the same number in the title, then other pages in language 1 with the same text, but other numbers are likely candidates to link to pages in language 2 with the same text as in the known links and matching numbers. Not all proposed merge candidates are correct, but the rate of correct guesses seems to be high.

Examples: User:Byrial/numbermerge/da-en for languages Danish-English, User:Byrial/numbermerge/ml-en for Malayalam-English.

I can make similar list for all language combinations for anyone interested if you tell which languages you want. Byrial (talk) 14:14, 24 June 2013 (UTC)

Cool. Could you make a list for Finnish-English? --Stryn (talk) 14:29, 24 June 2013 (UTC)
User:Byrial/numbermerge/fi-en is ready. Byrial (talk) 15:46, 24 June 2013 (UTC)
Thanks. I've merged all of those which were duplicates. Also Swedish-Finnish would be good list to check. --Stryn (talk) 17:09, 24 June 2013 (UTC)
And a list French-English? Tpt (talk) 15:03, 24 June 2013 (UTC)
On the way. Byrial (talk) 15:46, 24 June 2013 (UTC)
Please cs-en, sk-en and cs-sk. JAn Dudík (talk) 15:59, 24 June 2013 (UTC)
Can you add Italian-English? --ValterVB (talk) 22:21, 24 June 2013 (UTC)
Great idea, thank you very much! One possible add-on: You could check for conflicts. E.g. User:Byrial/numbermerge/fr-en contains "Q2806708 (fr:100 mètres), Q164761 (en:100 metres)". However, Q164761 correctly already contains fr:100 mètres (athlétisme), while fr:100 mètres is a disambigution page that should not be linked with en:100 metres. If you only list items not having a sitelink of the other language, you'll get rid of such false positives.
Btw. I'd like to order en-de ;). --YMS (talk) 09:23, 25 June 2013 (UTC)
Yes, the second item in each line can have links to both languages, but I will not just remove these cases from the lists as they can indicate an error which should be corrected: I have found cases where one of the pages was in a wrong item and should be moved. But I have now changed the program so it notes the sum of the number of links in the items and a warning in bold if there is links to the same languages. It will look like this:
(That was the complete nds-de and fy-de lists. I have moved de:594 v. Chr. from 590s BC (Q1312862) to 594 BC (Q1059205)). Will that be OK? Byrial (talk) 11:13, 25 June 2013 (UTC)
You will see a larger example of the new format at User:Byrial/numbermerge/simple-en with a couple of indicated link conflicts. Byrial (talk) 11:27, 25 June 2013 (UTC)
Yeah, great! --YMS (talk) 11:35, 25 June 2013 (UTC)
Wouldnt it be great if we have a page where we could submit such lists to where a bot would check and merge the items appropriately? ·addshore· talk to me! 22:52, 25 June 2013 (UTC)
I do not see how a bot would be able to check the items. But it would be cool to have a page where a human could submit checked items for a bot to merge. (That is if we can find a way to avoid that such a tool is abused to do unwanted merges.) Byrial (talk) 08:35, 26 June 2013 (UTC)
I imagine the bot would only merge items that had already been checked by users, the page to submit items to would probably have an access list, only those users could submit items! It would also be great to have some sort of client side application (such as WP:AWB be expanded to account for wikibase activities)! ·addshore· talk to me! 09:34, 26 June 2013 (UTC)
  • The English-German list is ready. It took a while to generate, but I am looking at ways to optimize my programs. I am ready to make lists for other language combinations, and I am also as always ready to make other types of lists if you have some good ideas. Byrial (talk) 08:35, 26 June 2013 (UTC)

New version

I completely rewrote the program and updated all the numbermerge pages. The old version was too slow (it took many hours for en-de while the new version took 3 minutes) and it did not find all cases that it should have found. Therefore many of the lists are considerably larger now than before. en-de and it-en have over 2000 lines and fr-en have over 3000 lines. The updated version will also warn about items with different numbers in different links. You are of course still welcome to order new languages combinations. Byrial (talk) 17:18, 27 June 2013 (UTC)

I'd like to order id-ms, please. Aurora (talk) 13:15, 2 July 2013 (UTC)
  Done at User:Byrial/numbermerge/id-ms. This is the first list made from version 3 of the numbermerge program which also tells which items the used patterns with numbers come from. BTW I am glad also to have non-European languages now!
Cool, thanks. Aurora (talk) 15:04, 6 July 2013 (UTC)
I will be through with User:Byrial/numbermerge/ml-en shortly can you please make a similar list for ta-en, hi-en.--Vyom25 (talk) 07:33, 4 July 2013 (UTC)
  Done: ta-en and hi-en. The Tamil Wikipedia doesn't seem to use Tamil numbers (೦௧௨௩௪௫௬௭௮௯), so I didn't learn the program about those. But the "hi-en" list have matches for both European and Devanagari numbers in the Hindi Wikipedia. Byrial (talk) 23:25, 4 July 2013 (UTC)
I've almost missed this thread. Would you please make a list for es-en? Thanks, Andreasm háblame / just talk to me 00:27, 10 July 2013 (UTC)

Mouse-over selection problem

Tracked in Bugzilla
Bug 51117

Unlike other Wikimedia projects, in Wikidata, items are selected when placing mouse pointer over a dropdown suggestion from a text box (for example dropdown suggestions from Search box).

Let me explain the problem.

  1. I want to search something in wikidata for example "Mathematics".
  2. I clicked on the search box (Assume the mouse pointer is just below the Search text box)
  3. I Started to type mathematics, some search suggestions appears in the dropdown. After a pause I continued typing, but before that, some of the search suggestions from the dropdown automatically enters into the text box and resulted with the text "Mathe, Dame d'Albretmatics" in the text box.

We can see this problem on every dropdown textboxes in Wikidata. I have tested some other Wikimedia projects but the problem is only at Wikidata. --Vssun (talk) 06:32, 9 July 2013 (UTC)

Reported a bug on this matter. --Vssun (talk) 16:55, 10 July 2013 (UTC)

Maintenance backlog

Seems like there is a lot to check in http://www.wikidata.org/w/index.php?title=Special:RecentChanges&tagfilter=new+editor+removing+sitelink --Zolo (talk) 08:22, 10 July 2013 (UTC)

There is always a lot to check. --Stryn (talk) 09:22, 10 July 2013 (UTC)
There are some instances where editor has removed link only to add it to another article. Can't we do something so those edits don't show up on that page?--Vyom25 (talk) 18:24, 10 July 2013 (UTC)
to add it to another item sounds better, yes, I agree, it would be easier to check those edits if it would be possible to use some kind of filter. --Stryn (talk) 18:37, 10 July 2013 (UTC)
Yeah, exactly.--Vyom25 (talk) 18:46, 10 July 2013 (UTC)

An example of hierarchy: astronomical objects and property P60 (P60)

In my sandbox I propose a hierarchy to manage astronomical objects that can be useful to manage infoboxes of Wikipedias. I know this is a very technical and specific matter, but it could be taken as example by other task forces. I'd like to discuss:

  1. the items involved in this classification;
  2. the relationship between them;
  3. how to show the hierarchy (I used a table, but I'm sure that exists a better way to show it).

Please, be bold. ;) --Paperoastro (talk) 17:34, 9 July 2013 (UTC)

That table is awesome. I left some comments in your sandbox. Emw (talk) 05:05, 10 July 2013 (UTC)

I left the following comments on this page. I am repeating them here as I think they are generic comments which apply to lots of other areas of work.

1. "Part of" relates objects but "sub class of" relates classes <AB star> "part-of" <AB star system> "part of" <CD constellation> but <binary star> "sub class of" <star> "sub class of" <astronomical object> and <binary star system> "sub class of" <star system> "sub class of" <astronomical object>.
Note that <binary star> isn't a star; it's a class of stars and it isn't a "sub class of" <binary star system> because a <binary star> is not a type of <binary star system>.
So "part of" creates a hierarchy of objects (with <the universe> at the top), and "sub class of" creates a hierarchy of classes (with a generic class such as <entity> at the top). Filceolaire (talk) 22:49, 10 July 2013 (UTC)


2. While it is true that "type of astronomical object" is a subproperty of "instance of" and could be replaced by "instance of" this would deprive us of certain advantages that "type of astronomical object" gives us compared to a more general property.

  • An item may have more than one "instance of" statement. Using the "type of astronomical object" property instead makes it easier for scripts to import the correct statement.
  • Using the "type of astronomical object" property means we can have a bot check for 'type violations' since this property should only be used to refer to items which are a sub class of (or a sub class of a sub class of) <astronomical object>.
Does that make sense? Filceolaire (talk) 22:49, 10 July 2013 (UTC)
This falls into the same bucket as "do we need a main type", to which the answer is no. See the discussion at primary sorting property, where I have argued that we do not need to check for consistency at all (see comment at 01:36, 4 July 2013 by me). See also, of course, the comments at Wikidata:Requests for comment/How to classify items: lots of specific type properties or a few generic ones?. It would make more sense to argue generalities there rather than here, and specifics left for the sandbox page. --Izno (talk) 23:04, 10 July 2013 (UTC)

Need to add the same property/value twice with different qualifiers

We use "start date" and "end date" on the "office held" property. But Grover Cleveland held the office of President of the United States for two non-consecutive terms. I need to add the property/value "office held/President of the United States" once with qualifiers for the first term's start and end date, then the same property/value again for the second term's start and end date. But it won't let me. How to represent the same office held, qualified by two different time periods? Jefft0 (talk) 06:42, 10 July 2013 (UTC)

I don't know what went wrong for you. I just tried something similar in Wikidata Sandbox (Q4115189) without problems. And I see in the history of Grover Cleveland (Q35171) that another user have added both periods of presidency. Byrial (talk) 09:05, 10 July 2013 (UTC)
Thanks. Now it's working for me too. I added the two non-consecutive terms for Jerry Brown as Governor of California. Jefft0 (talk) 16:28, 10 July 2013 (UTC)

I have related question: What about an actor playing different roles in the same movie? The Simpsons Movie has cast member Dan Castellaneta and I added the role qualifier for Homer Simpson. But he separately has the role of Krusty the Clown, so I added a separate statement for cast member Dan Castellanta with role qualifier Krusty the Clown. Is that the right way to do it? Jefft0 (talk) 16:28, 10 July 2013 (UTC)

The structure is right. But in my opinion the property 'cast member' is wrong. A new property 'voice actor' is already proposed, but yet not created. However: I think we should create it now, probably I'm gonna do it later this evening. --Nightwish62 (talk) 17:52, 10 July 2013 (UTC)
OK, thanks. For the film Austin Powers in Goldmember I added a statement for Mike Myers for each of the roles Austin Powers, Dr. Evil, Fat Bastard and Goldmember. (There is already an item for each of these characters!) Jefft0 (talk) 19:28, 10 July 2013 (UTC)
It looks like Hoo man changed The Simpsons Movie to have one statement for Dan Castellaneta with two role qualifiers. I asked Hoo man to join the discussion. I think each qualifier further restricts a statement, so it doesn't make sense to have qualifiers for two separate roles on one statement. It's the same argument for separate statements for two different terms for Grover Cleveland. Jefft0 (talk) 19:39, 10 July 2013 (UTC)
Interesting reasoning, also useful for the multi occurence point in time problem listed in this page. It should be written as a general guideline in Help:Modeling and in Help:statements. TomT0m (talk) 21:01, 10 July 2013 (UTC)
Yes. I would say the Glenn Gould item for award received Juno Award is wrong. There should not be 3 "point in time" qualifiers for the one statement: Maybe the award given in 1979 was revoked, so you need a "date revoked" qualifier. Where do you put it? Each of these needs a separate statement. Jefft0 (talk) 22:19, 10 July 2013 (UTC)

Proposal for Primary Sorting Property

Wikidata:Requests_for_comment/Primary_sorting_property is grinding to a halt and I don't think there is a consensus for or against P107 (P107) however there are strong feelings on both sides. Find below a proposed compromise that I hope we can agree on so we can move forward. I am posting it here as well to get the widest attention for this

  1. Property P107 (P107) is not the Wikidata Main Type. It is the GND Main type. There are 6 GND main type items - person (Q215627), organization (Q43229), event (Q1656682), work (Q386724), term (Q1969448), and geographical feature (Q618123) - and these can be added to any Wikidata page where they apply but should not be added to pages where they do not apply (such as Wikipedia non-article pages).
  2. Objects will have statements relating the object to a class of similar objects. This will be defined by properties such as P132 (P132), P168 (P168), P60 (P60), vessel class (P289) etc. Where a more specific property does not exist then instance of (P31) can be used to link Objects to Classes.
  3. Classes can be arranged in a hierarchy using the subclass of (P279) property. Note that this is used to link a class to a more general class. The elements of the first class should all be members of the more general class.
  4. Pages describing a class of objects will not, in general, have the instance of (P31) property. This is only used for wikidata pages describing individual specific objects.
  5. Some Objects can also be linked hierarchically to other larger Objects using properties such as member of sports team (P54), located in the administrative territorial entity (P131). Where a more specific property does not exist then part of (P361) can be used to link objects to larger objects.
  6. Note that part of (P361) will in general define a hierarchy of ever larger objects leading to the largest object (such as Universe (Q1)) while subclass of (P279) will define a hierarchy of ever more general classes leading to the most general class (such as "entity" (no wikidata page)).
  7. As these hierarchies develop we can look again at whether there is a need to define the items at the top of these hierarchies as Wikidata Main Types.

Please go to Wikidata:Requests_for_comment/Primary_sorting_property#Proposal to support or oppose or comment on this proposal. Filceolaire (talk) 00:48, 11 July 2013 (UTC)

List of items where xx-wiki's links have been deleted?

Is there any kind of possibility to see list of items where e.g. fi-wiki link have been deleted? It's possible via recent changes, but there is so much edits that it's impossible to see many this kind of items. --Stryn (talk) 18:41, 10 July 2013 (UTC)

So you mean to say that if it is possible to see changes in links related to say "en" wiki suppose and we have a list for that?--Vyom25 (talk) 18:45, 10 July 2013 (UTC)
I mean that sometimes I can see on fi-wiki this kind of lines, where some item has been deleted or the language link has been deleted:
So is it possible to see list of only this kind of items somewhere, where links from one specific wiki have been deleted. --Stryn (talk) 18:56, 10 July 2013 (UTC)
Understood. That would be a good idea as that will give contributors of that particular language a good idea about deleted links. And can take steps if necessary.--Vyom25 (talk) 18:59, 10 July 2013 (UTC)
I cannot directly help with this (as I only make reports based on current data as I do not read history files from the database dumps), but you can see a list of unconnected pages in fiwiki at fi:Toiminnot:Yhdistämättömät sivut. (Note: At the moment there is a lot of false positives at the list. It requires a null edit of the page to remove a false positive from the list. I have started a bot to do that with one page pr. second, so the list is rapidly shrinking at the moment.) Byrial (talk) 09:58, 11 July 2013 (UTC)

Q13701293

I want to ask it meets WD:N? the only one (ko) sitelink is ko:위키백과:오프라인 모임/2013년 7월 13일 page of wikipedia meetup plan in July 13th(KST) in Seoul. --DangSunM (talk) 08:50, 11 July 2013 (UTC)

Per WD:N it looks notable, but I would say that we should not add this kind of pages here. --Stryn (talk) 08:59, 11 July 2013 (UTC)

Unable to edit item

Hi, there appears to be a problem with editing the interwiki link for items. Having moved a page on the English wikipedia from "WNBA Draft" to "WNBA draft" to lower-case the second word in the title I find that I cannot save the change here to get the associated interwiki links to move. Having done the move yesterday I came back to change it today, thinking that there may be a time delay in allowing this to be done, but still no joy. I have done another similar move today and have exactly the same problem on that item. Keith D (talk) 10:57, 11 July 2013 (UTC)

It is a known bug. See Bugzilla:46451. A work-around is to first remove the old link, then add new link. Byrial (talk) 11:03, 11 July 2013 (UTC)
I tried the remove and re-add but on saving it automatically upper-cased the word so this did not solve the problem. Keith D (talk) 12:11, 11 July 2013 (UTC)
Well, it did seem to work for WNBA draft (Q1813540) as far I can see (although it do seem strange that the process increased the size of the item by 20 bytes according to the history page). Byrial (talk) 12:34, 11 July 2013 (UTC)
Interesting that the diff for my change shows it with a lower-case letter but the diff for your change shows it starting with a capital letter. Keith D (talk) 12:57, 11 July 2013 (UTC)
You changed the sitelink for enwiki, I changed the label for en. That is two different things. Byrial (talk) 13:09, 11 July 2013 (UTC)

a language to discuss how we use properties and how we model things in Wikidata

Hi, I want to develop a RfC on a (formal) model, maybe a grammar, to discuss and document proposals on domains of applications of Wikidata. It would be some help on Help:modeling to ask question, document ...

For example on the page right now there is a question : 1 statement with n qualifiers or n statements with n qualifiers ? The first solution (could) look like

<QItem> date of occurence <date>

  • (qualified by <value>)*

versus the second statement :

( <QItem> date of occurence <date>

  • qualified by <value>

)*

I think we should start a discussion on what we could put in a formal model like that, a minimal set of requirements would be:

  • for properties : express their domains, which walue they should take ?
  • for items : which, how many, ... statements they could have ?
  • for statements : how do we qualify them, question like my example questions ?
  • for whole domains of applications : how do we type items, how many items, how are they organised by statements ?

Of course, by Denny's famous blogpost these model should not be strictly enforced, so I propose to call them usually correct data model.

TomT0m (talk) 10:49, 2 July 2013 (UTC)

Sorry but your "new" discussions already exist: see Wikidata:Infoboxes task force and explain what is the difference please. Your approach is just a little larger but the purpose is the same: list properties for the differents objects which can be described in wikidata. Better stop your work on that new page and transfer the content on the different pages of the Infobox task force. Snipre (talk) 12:07, 2 July 2013 (UTC)
Then show me how what I just propose in this thread exists elsewhere, because I nether saw antyhing that looks like that anywhere. Help:Modeling is a different matter. TomT0m (talk) 16:30, 2 July 2013 (UTC)
I moved the discussion to the already begun RfC about documentation. TomT0m (talk) 11:52, 3 July 2013 (UTC)

I extended my notation proposition with variables : variable are bound to a value in a scope ie. between (). Thus in the following example Qserie has always the same value, there is several value for Qseason and more of Qep. 

<Qserie> instance of (P31) <television series (Q5398426)>
:(
::<Qseason> instance of (P31) <television series season (Q13416062)>
:::(
::::<Qep> instance of (P31) <episode (Q1983062)>
::::<Qep> part of (P361) <Qseason>
::::<Qep> part of (P361) <Qserie>
:::)+
:)*

I would say go for Turtle with some simplifications as we don't use namespaces. Jeblad (talk) 13:57, 7 July 2013 (UTC)

I would gladly take something already existing, but from your link it seems that turtle is a syntax to express a set of statements where what I propose is a model to discuss how we could format statement, am I missing something ? TomT0m (talk) 14:08, 7 July 2013 (UTC)
(I'm thinking out loud) I realise I am writing something similar to a query language ... a model actually corresponds to a request, every statement which are formated like that are in the set of results of this request. TomT0m (talk) 14:11, 7 July 2013 (UTC)
  • We should actively avoid inventing a language to describe properties if at all possible. We should build on existing conventions in the Semantic Web, ontology, and description logic communities. The best available option to describe properties that I'm aware of is OWL, the Semantic Web ontology language recommended by the W3C. In addition to its somewhat-verbose exchange syntax in XML, OWL also has a more readable "Manchester syntax" which I imagine would suit our needs.
Relevant OWL resources:
As a more general note, I think it would benefit the Wikidata community to refer to existing solutions from W3C recommendations for the Semantic Web when trying to solve problems on this project. Wikidata is not some radically new creature under the sun; it is in several important ways an iteration of a decades-old effort to represent knowledge in a machine-understandable fashion. People interested in formal knowledge representation and the Semantic Web have done an extensive amount of work outside Wikidata, and developed many relevant tools, to address the kinds of modeling problems that we have (and will) encounter on this project. We should stand on their shoulders. Emw (talk) 15:00, 7 July 2013 (UTC)
I agree on principles, it is the same family of stuffs, that said I want to see examples of real world example syntaxes, for example I don't really like the verbosity of the cardinality constraints in the model primer (plus building something inside the project, even if we get inspired a lot by those link, could help contributors to discover the domain). A syntax is just a syntax, if we find a more useable and adapted one in wikidata, it will be easy to build a transformation program into another one if the concepts maps, we will probably get a subset of them. TomT0m (talk) 15:27, 7 July 2013 (UTC)
A syntax is not just a syntax; it exists with (or without) tool support, solutions for common problems, etc. I think developing home-brew solutions to our ontology problems -- like developing a novel Wikidata-specific syntax for data modeling -- will make us less interoperable with the rest of the Semantic Web and weaken the project. We should strive to hew as closely to established conventions as possible. Emw (talk) 15:53, 7 July 2013 (UTC)
Actually it is, if they says the same thing you just need one more tool to do the translation to get into the standard tool ecosystem. TomT0m (talk)
"You just need one more tool" is an understatement. In addition to conversion programs, you would also need to duplicate formal documentation, copious examples, a body of questions-and-answers, etc., etc., etc. These already exist for established syntaxes. And who wants to maintain and learn a novel home-brew syntax when widely used syntaxes would suffice? Reinventing the wheel here would be a strategic mistake. Emw (talk) 19:43, 7 July 2013 (UTC)
There will be documentation duplicates anyway, I don't think than saying read this giant book will work for a lot of people who will actually contribute to this project, so there will be personalised policy, documentation, ... that will be made for actual contributors and what they really need. TomT0m (talk) 10:42, 8 July 2013 (UTC)
There are several issues here.
  1. Establishing standards/best practices for modeling data within Wikidata's current technical abilities. This is along the lines of the concept of design patterns. Your "1 statement with n qualifiers or n statements with n qualifiers" question falls under this, and from what I can tell, it's what Help:Modeling is about. As for the example, I'm not sure I see what the actual problem is. Could you give a concrete example, with specific properties and values?
  2. Establishing a (relatively) human-readable serialization/textual notation for WD data, in the context of Wikidata's current technical abilities. Since exporting data to RDF is already planned (P2.6) in some detail, Turtle seems like the way to go. I see no reason to reinvent the wheel.
  3. Expanding the capabilities of Wikidata to support class descriptions, i.e. describing/defining a class in terms of its properties, including the ones from its superclass. I support this as a direction Wikidata should be heading in, and I hope this will eventually receive some development time. Once again, we should definitely not try to reinvent the wheel--OWL is a natural choice for this as it's been developed with the Semantic Web in mind and is based on formal logic, enabling inference. If and when we adopt OWL, Manchester syntax seems like a good choice for serialization.
Silver hr (talk) 20:55, 11 July 2013 (UTC)

Turtle vs. Manchester syntax

Two primary candidates for expressing data models on Wikidata seem to be Turtle (http://www.w3.org/TR/turtle/) and Manchester syntax (http://www.w3.org/TR/owl2-manchester-syntax/). These are both OWL syntaxes that give more readable representations of OWL data than is available in the language's canonical RDF/XML exchange format.

An article "OWL Syntaxes" by Matthew Horridge, who works with W3C on OWL, explores these options. I found examples comparing Turtle and Manchester syntax helpful in comparing the two syntaxes:

Turtle: 

:Teenager rdf:type owl:Class ;
   owl:equivalentClass [ rdf:type owl:Class ;
       owl:intersectionOf ( : Person
           [ rdf:type owl:Restriction ;
             owl:onProperty :hasAge ;
             owl:someValuesFrom [ rdf:type rdfs:Datatype ;
                 owl:onDatatype xsd:integer ;
                 owl:withRestrictions ( 
                     [ xsd:maxExclusive "20"^^xsd:integer ]
                     [ xsd:minExclusive "12"^^xsd:integer]
                     )
                 ]
             ]
          )
       ] .

Manchester syntax: 

Class: Teenager
   EquivalentTo: Person and (hasAge some integer[> 12 , < 20])

Manchester syntax seems considerably more compact and easier to read and write. It is also supported by Protege, a widely-used editor and browser for ontologies that would (in time) probably be helpful for exploring Wikidata. Emw (talk) 15:39, 7 July 2013 (UTC)

Seems OK to me, can you try to translate my serie example ? TomT0m (talk) 16:29, 7 July 2013 (UTC)
Sure. Your example seems to be describing a possible model for the class 'television series', specifically that all individuals of the class 'television series' have one or more seasons, each of which has one or more episodes.
Your proposal:
<Qserie> instance of (P31) <television series (Q5398426)>
(
    <Qseason> instance of (P31) <television series season (Q13416062)>
    (
        <Qep> instance of (P31) <episode (Q1983062)>
        <Qep> part of (P361) <Qseason>
        <Qep> part of (P361) <Qserie>
     )+
)*
Manchester syntax:
Class: television series
    SubClassOf: hasPart season min 1
Class: season
    SubClassOf: hasPart episode min 1
The OWL 2 Primer has many more examples of how Manchester syntax can be used to describe classes, individuals, properties, etc. As shown above, cardinality restrictions are quite easy to read and write in Manchester syntax. You can show and hide the various OWL syntaxes throughout the OWL 2 Primer by toggling the buttons at the end of Section 1.2: http://www.w3.org/TR/owl2-primer/#OWL_Syntaxes. Emw (talk) 19:19, 7 July 2013 (UTC)
Main problem with Manchester is that it relies heavily on class and subclass constructs and we don't have that in Wikibase. It is partly in the model, but so far it isn't in the implementation, and to my knowledge isn't planned to be included anytime soon either. Not sure if that pose any serious problems as long as we know the limits of the model. Jeblad (talk) 19:54, 7 July 2013 (UTC)
I suspect that class and subclass constructs will become part of Wikidata whether they're directly supported by Wikibase or not. P31 and P279 are explicitly based on rdf:type and rdfs:subClassOf, respectively, and there have been discussions (like this one) that are essentially trying to bring a Semantic Web-based notion of classes to Wikidata. Emw (talk) 20:08, 7 July 2013 (UTC)
We need transitive properties to fully support instanceOf and subclassOf. But I agree, in some way or another this must be supported and I think the way the datamodel proposes are the right way. Only alternative I see without this is some kind of prototype-based inheritance, but that has a lot of other problems. Jeblad (talk) 20:28, 7 July 2013 (UTC)
Could you point me to which part of the Wikidata data model you're referring? I inquired about the Wikidata development team's plans to support transitive properties a while ago in Wikidata:Contact_the_development_team/Archive/2013/04#Transitive_properties_and_SPARQL, and Denny said "support for transitive properties is a bit further down the line". Transitive properties are currently listed in Category:Ordering_properties. Emw (talk) 20:55, 7 July 2013 (UTC)
Tracked in Bugzilla
Bug 50911
I've filed a ticket to add support for transitive properties in Wikidata queries: https://bugzilla.wikimedia.org/show_bug.cgi?id=50911. Emw (talk) 23:02, 7 July 2013 (UTC)
There are two snaks that makes it necessary to implement transitive properties; m:Wikidata/Data_model#InstanceOfSnak and m:Wikidata/Data_model#SubclassOfSnak. If those two exists then transitive properties must somehow be copied or transfered down the created hierarchy or the subclassed or instantiated item must see its parents. If an entity A is a subclass of another B, then the properties of A should somehow inherit all of the properties from B. The same goes for instantiation. At least it must be made a decision if our inheritance is classical or prototyped. It could be other mechanisms to do this in addition to this or instead of this, and there could also be constraints on how to do this if we want to conform to RDF or OWL.
As a side note we can avoid those snaks as long as we only support Wikipedia and tries to be a value store, but as soon as we try to implement anything for Wiktionary without them we will run into trouble. We need them desperately for word classes. Jeblad (talk) 14:32, 8 July 2013 (UTC)
Imho this is not a problem at all if Wikidatians understands that. The logic of inference will be coded in bots at first for automated stuff, and for the model discussion and documentation part it is not a problem. For those who want's to use database dumps and RDF exports it is not a problem either as they will use external tools. TomT0m (talk) 10:09, 8 July 2013 (UTC)
It is a pretty big problem because standardized tools can't be used. If we don't use classes, we don't use instantation, we don't use normal identifiers, well the chance of being able to use normal standardized tools are pretty slim. Jeblad (talk) 14:32, 8 July 2013 (UTC)
From what I understand you should not expect anything like that from the development team, instance and subclass will remains just relations, and nothing more, no strong constraint from the software will be implemented with them. See Denny's blogpost about this subject. Any structural constraints but the basic datatypes of values are likely to come from community decisions and will be enforced by bots and humans. But I don't really see your point where this would make impossible to use external tool with Wikidata. TomT0m (talk) 15:41, 8 July 2013 (UTC)
Revisiting Denny's Restricting the World post, I view it as signaling that support for restricted types will not be implemented in Wikibase, not that support for InstanceOfSnak and SubclassOfSnak will never be implemented. It's possible to do lots with 'instance of' (rdf:type) and 'subclass of' (rdfs:subClassOf) without support for restricted types (i.e. owl:disjointWith), so I don't think being against restricted types should be interpreted as necessarily being against the idea of organizing concepts into a taxonomy. An overly broad application of type restrictions and constraints seems like it would violate the open world assumption, a basic tenet of the Semantic Web.
That said, I agree with TomT0m that it would probably be best to assume that instance of (P31) and subclass of (P279) will not be baked into Wikibase soon. The "on hold" status for those snaks was noted in January, but I haven't been able to find any explanation for why that is.
Even without explicit built-in Wikibase or Wikibase client support for P31 and P279, however, I think it will be possible to treat them as transitive properties in time. For example, a patch for bug 47930 seems like it would allow (some) type inference in Wikibase clients with Lua; and bug 50911 is a request for a similar feature in Wikibase queries. Emw (talk) 02:38, 9 July 2013 (UTC)
I think "Restricting the World" is about restricted types, and not about restricting development of a taxonomy. That said the community is pretty busy creating tools for restricting types. I would prefer tools that says something is unusual instead of forbidden. When it comes to "instance of" and "subclass of" the reasoning is mostly about the additional complexity of transitive properties and whether the system can work without them. Its about priorities on a limited budget I guess, and implementation of them are pretty far down on the list. Jeblad (talk) 03:15, 10 July 2013 (UTC)

merge.js error

I've merged two items: Nuristan (Q167485) and Nuristan (Q12828819) with merge.js, but it has removed labels from first item.--Ahonc (talk) 16:41, 11 July 2013 (UTC)

Hi. This was a bug of Wikidata and it is fixed now. [Without any modification to merge.js code] now it is merging right. –ebraminiotalk 21:08, 11 July 2013 (UTC)

a personal note and a secret by Denny

Heya folks,

I am actually on vacation at the moment but I think you want to read this email by Denny. --Lydia Pintscher (WMDE) (talk) 20:55, 11 July 2013 (UTC)

Hello from Adam

Hi! I'm Adam, or (Addshore) and have just started working at WMDE on Wikidata which is contributing towards my placement year at University in the UK.

I will be around for at least the next 6 months which I am sure will be great! I'm going to be working on lots of bits and pieces which I hope will keep everyone happy including usability testing, bug fixing and triage, analysis of usage patterns, api stuff and communication (among others) !

Adam Shorland (WMDE) (talk) 14:21, 1 July 2013 (UTC)

Welcome and good luck. Snipre (talk) 15:59, 1 July 2013 (UTC)
Autopatrolled your staff account after marking your userpage as patrolled. Welcome :) Ajraddatz (Talk) 17:35, 1 July 2013 (UTC)
Good luck! :D Del♉sion23 (talk) 04:39, 3 July 2013 (UTC)

Identifier mess…

Trying to model some real world data, the Norwegian Central Place Name Registry, I run across the identifiers. Now it seems like everyone that has some kind of identifier to an external resource insists on making a special property for just that identifier. That will make the number of types explode and make reuse difficult if not impossible. Some types of identifiers are made for external use and should live on as special properties, like ISBN numbers, but most of them can be merged into (ehm) one.

Wikidata is linked data, and as such we use dereferencable uris to identify external entities and to divide referencing the entity from its description. Often we will only be able to link to the description and not to the entity, that is the link is not dereferencable. That is a bummer, but most of the time we can silently forget that we only have one part of the link. We do make an error, but for now the error might be acceptable.

If we can create a working descriptive uri that reflects the identifier of an entity, and that descriptive uri holds the context where it is a valid identifier, then I think we should not create a new unique property only for the id. In those cases I think we need a property "same as" that holds an uri to the same external entity as our internal item. All uris listed as "same as" that returns a html page is a description, anything else are assumed to be data about the entity.

That means Senjahopen (Q2666735) (w:Senjahopen) will have a "same as" that holds the value "http://faktaark.statkart.no/SSRFakta/faktaarkfraobjektid?enhet=301346", which is just another description of the same entity. They even have data endpoints but I'm not sure they are dereferencable. A statement like this can have additional qualifiers, especially qualifiers that identifies the organization.

I think this is sufficient for most identifiers used in WikiLovesMonuments, that is if URLs are available in time. Jeblad (talk) 20:11, 6 July 2013 (UTC)

However, if statkart.no changes its URL scheme in some years, e.g., to "http://statkart.no/faktaarkfraobjektid?enhet=301346", all the links are broken. With a special ID, you just need to fix one property at one place. And changes in URL schemes happen very often, while as soon as third party data providers define an ID, this will in many cases stay constant.  — Felix Reimann (talk) 22:02, 6 July 2013 (UTC)
Objects in linked data are supposed to be identified by their uri, what we do now is to extract their local identifiers and use that to construct an external identifier. That is in my opinion a flawed approach. Said in another way; we need to connect to the external description, not only for us to follow a link to a readable page, but for machines to be able reach out and enrich our machine readable content. For that to work we need dereferencable uris as identifiers. Jeblad (talk) 22:11, 6 July 2013 (UTC)
I find it a bit strange to identify objects by a lengthy URI while their explicit identifiers are usually short strings ("Navneenhets-id: 301346"), and many Wikipedia templates should only show the short ID. I can imagine that it makes sense to have the full links for external users, but that would be much better if that could be done through sitelinks similar to those for Wikipedia (I do not know how machines are supposed to follow sitelinks, but clearly, there should be an easy way). --Zolo (talk) 08:05, 7 July 2013 (UTC)
Why should we show the external sites internal ids? We should identify and point to the entity as described on the external site, not its internal id. Actually we disintegrate the values used by the external site and store them locally in our site. That is the opposite of what we should do in a linked data environment. In a linked data environment you provide the links that make the sites interact. Now we are turning into a site where we provide values from the external sites, effectively becoming an more or less unconnected island in an otherwise highly connected world.
The "same as" (owl:sameAs) is perhaps the most important property to create connections between entities in linked data as it can be used to enrich provided items. We can become a value store for Wikipedia without this, but we will not be very usable for anything else. Jeblad (talk) 14:20, 7 July 2013 (UTC)
Maybe this points to the need for a new type, something along the lines of a sameAsType, where we can specify the local ("internal") ID on a particular item, and populate a list elsewhere with the URI associated with that claim-ID. That way, we do not face the fear of having to bot change thousands of items when an external site decides to change their site-structure, which is the reason why it has been done the way it is. You're concerned about the semantic implications, yet we're living in a real world where there is only so much volunteer power and only so many edits we can make in a given period of time. A database, in fact, would construct the URI the same way that we've done, I have no doubt; it would separate the unique ID (the string of alphanumerics that indicate an "internal" ID as you put it) from the general ID (the rest of the URI) for precisely this reason. --Izno (talk) 15:34, 7 July 2013 (UTC)
I'm for a new type too that can be used to keep information up to date. There are several alternatives:
  • "external record" property or just a datatype (either would require: Provider (used to get the stem), Unique ID, Point in time)
  • new datatype similar to URL (link+point in type)
  • specific properties for each site (as it is now)
Each option has its advantages, what we have now it is not that bad because it is controlled which sites are linked. A new datatype is maybe feasible when URLs are supported. --Micru (talk) 16:09, 7 July 2013 (UTC)

I think that the two approach are important: we should store the internal identifiers because they are more stable and more easy to manipulate and the software should be able to transform them to linked data URIs in order to proposed an easy sharing of informations. These constraints are compatible: we can imagine that the internal identifiers are linked with an URI pattern, shared with all ids of the same provider. I see two ways of doing that:

  1. Use the sitelinks system by creating a group of links called "external" that regrouped all the not Wikimedia providers. I have made last year a proposal in that sense.
  2. Create a special datatype "identifier", extends of string, that store a string (the internal idenfier) and output it as an URI from a pattern set in the property page. This system looks more difficult to implement but also far more powerful (no need of 1-1 relationship, easiness of configuration...). Tpt (talk) 17:01, 7 July 2013 (UTC)
Note that owl:sameAs does not imply that there are a single uri structure for a specific content provider. In fact the complete uri is the identifier and some part of it might change without the overall uri loosing its meaning as an identifier. Splitting of some part of it and expecting it to be possible to regenerate a working uri is doomed to fail. Further I don't think we should mess with the sitelinks, those have a very specific purpose related to reuse in clients. Yes they are "sam as" but with a very specific interpretation in our context. The statements are about values and links, or said another way they are our implementation of triplets. A "same as" is such a triplet with the uri as the subject object [always swaps them ;/]. Jeblad (talk) 17:09, 7 July 2013 (UTC)
I do not undestand what is wrong with using sitelinks. It does not force clients to use it, and if the want to use it, that's great. Many templates use these identigiers and it seems rather difficult to get templates like en:Authority control or en:Template:PBB/5649 from a generic property. --Zolo (talk) 18:03, 7 July 2013 (UTC)
It's just another variation around the classic specific properties versus one generic property. It may be possible to make everyone happy by transforming specific properties into one gerenic property whose supposed to be qualified with what is now specific property, or maybe the converse. This does not reduce the number of properties though. And maybe what it is really is an information about all statements constructed with those properties, so maybe a meta information of the property itself. TomT0m (talk) 18:14, 7 July 2013 (UTC)
As I said in the first post; some identifiers like ISBN are used as external identifiers, this is not about those. A lot of other identifiers are only used internally at the specific service provider. When we extract those internal identifiers instead of using the uris we create a value store instead of a linked data triplet store, and we disconnect ourselves from the rest of the world.
The linked data principles introduced by Tim Berners-Lee are the following[2]:
  1. Use URIs as names for things.
  2. Use HTTP URIs, so that people can look up those names.
  3. When someone looks up a URI, provide useful information, using the standards (RDF, SPARQL).
  4. Include links to other URIs, so that they can discover more things.
There is also a bit about making those uris machine readable, but this is enough in this context. Jeblad (talk) 18:28, 7 July 2013 (UTC)
It is a mapping problem. I cite Wikidata technical proposal
[the project will not undertake by itself to provide mappings to the Web of Data; however, it will provide an infrastructure for others to build that. The question needs to be asked to developers to see how they see things on these problems. TomT0m (talk) 18:37, 7 July 2013 (UTC)
Also note that the complete url is generated by the software himself generates the full url, I don't know the magic but maybe it is one of the mechanism that were thought in this proposal. TomT0m (talk) 18:41, 7 July 2013 (UTC)
I think you misunderstands the problem. The way identifiers are handled now blocks any later reuse. Mapping is whats done with our data at a later stage if we provide and keep the necessary data. Said another way we shoot ourself in the foot and insists that this is the right way to do it. Jeblad (talk) 18:48, 7 July 2013 (UTC)
Most properties listed MediaWiki:Gadget-AuthorityControl.js correspond to a Wikipedia template parameter, and very often one that is used in such a way that it would make sense to use Wikidata. Wikidata does not use RDF / SPARQL either. I would really think that if it is technically possible, there should be the Wikidata / sitelink version for internal use and the RDF / URL conversion for external users. --Zolo (talk) 19:30, 7 July 2013 (UTC)
Our human readable version is Q1, while our machine readable version is Special:EntityData/Q1.rdf. The dereferencable uris are not fully operational on our site (?), but they are described on m:Wikidata/Notes/URI_scheme. (Actually I wonder if the content negotiation is set up on http://www.wikidata.org/entity/Q1 with a 302, outcome of the negotiation either redirects to the first one for html (the description) and the last one for rdf (a proxy for "the real thing") after a 303. This is odd, it should be a 303 and then a 302.) Jeblad (talk) 20:18, 7 July 2013 (UTC)
Against use of url as value for identifier: if you have a small experience of url use as reference, you know how often the database structures change leading to broken links. And it is not the task of wikidata to provide links to other sites, this can be done in wikipedia with a template which can be easily changed if the url is modified. Snipre (talk) 12:55, 8 July 2013 (UTC)
Is this a value store or is this project a part of the semantic web? If the later we must provide the necessary identifiers as used by the rest of the semantic web, that is not the responsibility of our clients. See for example W3: 3. URIs for Real-World Objects. Jeblad (talk) 14:05, 8 July 2013 (UTC)
We'd like to be both! However, there are two conflicting issues, one of which either you do not recognize or do not care about. The first is that we want to be part of the Semantic Web (this is the one that both you and we recognize). The other is that we do not want to need to maintain the full structure of a URI on thousands -> millions of items. Either you do not have real experience on the Wikipedias needing to do that, you do not care, or you are not listening, because it is a very real problem that we do not want to need to deal with. As I suggested above, the probable solution to the problem is for the developers to extend the URIType to allow us to define one part of the URI in one place and the other part in another place. Any solution which does not fix the possible problem we have as users will not be welcome. Period. End of story. --Izno (talk) 16:25, 8 July 2013 (UTC)
@Jeblad The idea of the semantic web is not taking account of the unstability of the web: broken links are a reality and please consider that. The concept of semantic web is stil a concept and needs more development before becoming a reality: we need more reliable online sources and right now most of the knowledge is still offline, so yes we need to store more data before thinking of semantic web. Snipre (talk) 20:05, 8 July 2013 (UTC)
In general I agree that in order to be a good Linked Data citizen, we should use Uniform Resource Identifiers as identifiers. I also agree that we should use owl:sameAs to link to individuals in other datasets, since that's more or less the standard, and owl:equivalentClass and possibly owl:equivalentProperty for classes and properties. However, there's also the real world issue of others not necessarily being good Linked Data citizens and changing their URIs. Also, I'm not sure what Izno means with "maintenance" of items, but I suspect it might mean that a correct property value in some item might be changed by someone and made incorrect, and if we have millions of them, there's a very low probability that the destructive change will be seen and undone. I think this is primarily a policy problem, and less a technical one. We cannot avoid having millions of items and statements, and I suspect we'll have to have some kind of curation mechanism and prevent certain classes of users from directly modifying verified statements (or at least review such changes). Silver hr (talk) 23:31, 11 July 2013 (UTC)
Maintenance of items which have links to those Bad Linked Data citizens who change their URIs. --Izno (talk) 23:40, 11 July 2013 (UTC)
Presumably, if that happens, they'll change their URI scheme in a consistent way, which means we could update our URIs automatically via bot. I expect this kind of thing to happen rarely though, as the awareness of the Linked Data concept and its rules grows. Silver hr (talk) 11:20, 12 July 2013 (UTC)

Please do not use owl:sameAs on data items! Let's say we have information about Paris (Q90) in another database, with the URI <http://example.com/data/e53ba4f>, then:

What we really want to say is that the two documents describe the same thing. As you can see from https://www.wikidata.org/wiki/Special:EntityData/Q90.rdf, we use schema:about to do this. So:

This is formally correct. However, the above is a statement of fact. Wikidata doesn't allow you to state facts, only claims. So the pragmatic solution to this would be:

  • Have a property (with type "url") that means "Online dataset about this" - let's call it P888.
  • Set this property on Q90 with <http://example.com/data/e53ba4f> as the value.

This way, we have a claim saying that <http://example.com/data/e53ba4f> is describing Paris. Which is what John originally wanted, I suppose. But this is not the semantics of owl:sameAs. -- Duesentrieb (talk) 12:25, 13 September 2013 (UTC)

no way to represent | in aliases?

Tracked in Bugzilla
Bug 43136

I want to add the alias Mac|Life to Q1161179, but it won't display properly. If I try to put the | in just using the key, instead of the code beginning with &, it gives two aliases, "Mac" and "Life", not Mac|Life. If I use the code beginning with &, it shows the code itself, not the |

Anyone able to help?

Sven Manguard Wha? 20:57, 11 July 2013 (UTC)

P.S. trying to describe a problem with | is really hard.

It looks like "file a bug" is the correct answer. :) --Izno (talk) 21:03, 11 July 2013 (UTC)
  Filed Sven Manguard Wha? 21:15, 11 July 2013 (UTC)
Indeed there is currently no way to do this! The api uses the | character to split up each alias in a list. ·addshore· talk to me! 07:37, 12 July 2013 (UTC)

New database dump and new reports

There is now a 2013-07-10 database dump, and I have updated some (but not all) of the reports listed on my user page. What is new this time (apart from some changes in the format) is that we have coordinates from 5 other globes than the Earth (globe list). I have updated the lists of possible merge candidates based on links with common numbers and same Commons category. The commonsmerge lists now indicate when the listed items are used as values in statements (which means that these statements should be updated if the item is merged to another item). The numbermerge lists do not yet have a use indicator, but it is planned. Please tell if you want to use lists for new language combinations . Byrial (talk) 10:51, 12 July 2013 (UTC)

Interesting, thanks. Stupid side question, but how do you choose the globe for coordinates ? --Zolo (talk) 12:28, 12 July 2013 (UTC)
I suppose that you for now have to use the API intended for bots – which is hard to do if you are not a bot. You cannot even see in the normal user interface that the crater Beethoven (Q48666) is located on Mercury (Q308) but it is indicated in the database. Byrial (talk) 12:43, 12 July 2013 (UTC)

Inrterwiki

zh:扎加 correspond to (fr:Tragyal, en:Tragyal - already linked Q3536477) can anyone fuse to zh? --Rédacteur Tibet (talk) 11:16, 12 July 2013 (UTC)

  Done, you can use the "merge.js" tool (selectable in your preferences/gadgets). --Zolo (talk) 12:34, 12 July 2013 (UTC)
Many thanks. --Rédacteur Tibet (talk) 12:51, 12 July 2013 (UTC)

Another generic & qualified versus specific case

I see that lyrics by (P676) is a recently created property (unfortunately I did not took part in the creation discussion). However I think this kind of authorship properties could grow endless. For example (correct me if I am wrong) there is actually no property for choregrapher. Cinderella (Q5120428) Cinderella (Q1990253) whereas there is a generic creator property which can be qualified as much as we want. Like in other cases, I don't really see the value of creating many properties. TomT0m (talk) 15:01, 12 July 2013 (UTC)

It looks like the property only had one supporter. But I generally see no problem with a certain amount of trial and error. It is a steep learning curve for all of us. I would say that we should give the property a few weeks to prove itself. If nobody is using it in a way that could not be handled with your solution we can start a RfD. --Tobias1984 (talk) 16:11, 12 July 2013 (UTC)
I don't know why you're talking about just "one supporter", when the archived property proposal discussion clearly shows there was three supporters (even one hasn't sign his vote - I think it's too much effort to retrieve his username/IP out of the creative work history). Fact is, there was three supporter (including me, that's right) and no opponent at all in a time period more than 2 month! That was the reason why I created this property together with two other properties on the same day which where also voted to be created (Property_talk:P674 and Property_talk:P675). Also I rejected (and archived) another property proposal on the same day, see here, which was clearly declined by the community. So as you can see I just did some clean-up on this day (6. July), because the PP-sites gets longer and longer and nobody seems to care about. So I feel a little bit offended when my clean-up was regarded as a 'single supporter action'. I just gave a last pro vote of an existing proposal discussion and closed the proposal immediate after this, as all of them has at least 3 supporters and no opponents.
Back to the initial topic: Yes, it is indeed yet another generic & qualified versus specific property" discussion, and to be honest, I really get tired about this topic, because there are running discussions about this on several property proposals and also at least two running RfDs already and I can't see any progress anywhere. We're blocked to enter statements for month already, just because we haven't the necessary properties. --Nightwish62 (talk) 19:07, 12 July 2013 (UTC)

Renaming "Translation administrators" to "Translate extension managers"

Hello all,

Translation administrators serve a vital function on this project. However the function that they serve is very dissimilar to that of administrators (sysops), and, at least in my opinion, does not require the same level of community vetting and trust.

However because the title "Translation administrators" contains the word "administrators", people often elevate the position to a level of, for lack of a better word, gravity, that the position shouldn't hold. In other words, in discsussions on user rights, translation administrators tend to get lumped in with admins and 'crats rather than with rollbackers and property creators. Case in point: the discussion at Wikidata:Requests for comment/Defining inactivity brings up translation administrators, but no other permission outside of what I consider the 'advanced permissions' (admin, crat, CU, and OS).

I think that a rename to "Translate extension managers" would help people that aren't as familiar with the different permissions on this project better understand the level of trust that the permission holds (it's a permission that requires a request be filed, but not one that's at the admin/crat/CU/OS level), while having no negative impact on the role itself or the ability for rights holders to do their jobs.

Thoughts?
Sven Manguard Wha? 20:55, 12 July 2013 (UTC)

Good idea. That actually makes a lot of sense. (I'm fine with Translate extension managers, but I don't have a strong feeling about that—just that it makes sense to drop the word "administrator" from the title.) StevenJ81 (talk) 23:31, 12 July 2013 (UTC)
Will you then raise the same question on other wikis where extension Translate is enabled? It will be funny to be a TEM here but TA — on Meta-wiki, MediaWikiWiki (and also Commons, WikimaniaWiki, Outreach and wherever else)   -- Ата (talk) 06:17, 13 July 2013 (UTC)

Propagation of changes to the Wikipedias currently lagging

Changes to Wikidata are currently propagated to the Wikipedias with a lag of several hours, but this should be fixed during the next few hours.

The Dispatcher, who is responsible to push the edits from Wikidata to the individual Wikipedias, choked yesterday on some edit. We did not notice until the morning (thanks to the community for reporting on various places). We got the Dispatcher running again. The backlog then was about 19 hours, and is now going down again, it seems roughly at a rate of two hours per one hour, so it should have caught up in about half a day. You can see the current status on wiki.

We currently do not know why the Dispatcher got stalled, and also not on which edit exactly. We simply skipped a few edits, and it started working again. We will continue investigating. Because of that, it might happen again any time. We keep watching the stats. A detailed description of our current status can be found on the Wikidata-tech mailing list. --Denny (talk) 11:32, 13 July 2013 (UTC)

The Wikipedias have all caught up now. Fingers crossed this does not happen again! --Denny (talk) 14:20, 13 July 2013 (UTC)

Request to merge the same page

This and this articles talling about the same subject - japanese religion shinto. I think, that it should be merging. Yorukera (talk) 15:03, 13 July 2013 (UTC)

  Merged. Littledogboy (talk) 16:01, 13 July 2013 (UTC)
Thank you very much Yorukera (talk) 16:08, 13 July 2013 (UTC)
If you would like to know how to merge items yourself in the future, you can read Help:Merge. Del♉sion23 (talk) 16:36, 13 July 2013 (UTC)

Need simple way to add Commons category interwiki links

Before wikipedia used the wikidata automated tool that displays links to other wikipedia language projects, it was simple to copy the list of interwiki links from any wikipedia article and use it in a Commons category. One would just copy the list, add the source language link and paste to the end of the commons category page.

Well, now I am quite stumped. What is needed is a a simple way to trigger wikidata to show the language interwiki links in each Commons category.

I tried and failed to do this at [3], but I may have succeeded some months ago only by tedious trial and error.

How about a means for the wikidata page to extract all the links as a single page in copyable plaintext? It appears that functionality has been lost and is sorely needed (by me if noone else). I will back link my posting from the Village pumps at wikipedia and Commons. -84user (talk) 16:31, 13 July 2013 (UTC) (cross linked from Wikipedia:Village_pump_(technical)#Need_simple_way_to_add_Commons_category_interwiki_links and Commons:Village_pump#Need_simple_way_to_add_Commons_category_interwiki_links. -84user (talk) 16:52, 13 July 2013 (UTC))

Wikidata and GlobalUsage for files at Commons

Tracked in Bugzilla
Bug 46358

We are going to have a bit of an issue with the links in WD where they reference an image at Commons, as these images don't show up in GlobalUsage for the files at Commons. So when a wiki uses the WD image property to call the image for an article (usually via Template) the image will now be referenced in the global usage for the file at Commons at the particular wiki, however, there is no reference to the file's usage (via property reference) at Wikidata. So if a file is globally replaced from Commons there is no evident means for Commons to know that the:

  1. file is linked at Wikidata;
  2. replacement of the file link should be done at WD rather than in the wiki where it is showing up as being linked.

It is only mildly problematic at the moment, however, as the use of the property grows it is going to become a larger problem.  — billinghurst sDrewth 13:28, 13 July 2013 (UTC)

Bugzilla report was created in March based on my suggestion, but functionality is still not there :-( I encountered links to deleted files already. --EugeneZelenko (talk) 13:52, 13 July 2013 (UTC)
I had to struggle through some template looking before I worked out WITH was going on. Who do we need to nag for it?  — billinghurst sDrewth 11:44, 14 July 2013 (UTC)
Is it possible that we could look to actually display a small thumbnail of the image at WD, so that it shows in Commons Global Usage? Then the replacement from a Commons perspective is at least evident, if it is not directly able to be replaceable.  — billinghurst sDrewth 11:50, 14 July 2013 (UTC)

Merge

Q1707372 and Q3743715 are the same95.250.194.52 08:44, 14 July 2013 (UTC)

  Done--Ymblanter (talk) 10:55, 14 July 2013 (UTC)
If you would like to learn how to merge, please see Help:Merge. Cheers :) Del♉sion23 (talk) 11:52, 14 July 2013 (UTC)

Technical issues 14/07

...does not seem to be working well, cannot add/remove sitelinks, gadgets have disappeared. Littledogboy (talk) 12:22, 14 July 2013 (UTC)

I am also experiencing issues. All the gadgets have disappeared. Del♉sion23 (talk) 12:52, 14 July 2013 (UTC)
This is a current known global issue and the ops team are working on it. The problems currently are affecting gadgets and the api. Hence wikidata will not work as expected for a while. ·addshore· talk to me! 13:05, 14 July 2013 (UTC)

Preview not working

The "preview" facility seems to have stopped working for me. The link is there, and it goes to the anchor "#x-articlepreview", but no preview appears. Is anybody else experiencing this? (Firefox 22.0 if it matters). --ColinFine (talk) 00:56, 12 July 2013 (UTC)

Which preview facility exactly? ·addshore· talk to me! 07:45, 12 July 2013 (UTC)
I think that ColinFine means this: MediaWiki talk:Gadget-Preview.js#Problems. --Stryn (talk) 07:56, 12 July 2013 (UTC)
The html of the item pages did change on Monday. That is likely the reason. Aude (talk) 09:47, 12 July 2013 (UTC)
Sorry, I had completely forgotten that Preview was I gadget I had enabled. I thought it was standard. Should I then report this somewhere? --ColinFine (talk) 16:53, 12 July 2013 (UTC)
*points at MediaWiki_talk:Gadget-Preview.js* :) ·addshore· talk to me! 07:52, 15 July 2013 (UTC)

Requested to the bots

Hello, we have changed the namespaces in Chechen Wikipedia, so all links to templates like Куцкеп:(Name) should be changed to Кеп:(Name). Similarly, Categories - Кадегар:(Name) to Категори:(Name). --Дагиров Умар (talk) 19:05, 13 July 2013 (UTC)

For your info: Pr. 2013-07-10 where was to Chechen Wikipedia (ce):
  • 460 template links (namespace 10)
  • 598 category links (namespace 14)
  • 0 help links (namespace 12 - Name changed from "Гlо" to "ГӀо")
  • 1 file link (namespace 6 - Name changed from "Хlум" to "Файл")
I am not sure if the bot API select all items which have sitelinks to a specific wiki, so I made a list at User:Byrial/Chechen template and category links. Byrial (talk) 22:12, 13 July 2013 (UTC)
I moved the request to Wikidata:Bot requests#Requested to the bots. Byrial (talk) 09:38, 15 July 2013 (UTC)

A quick quip about what data could be stored here to make this site a more valuable resource

Let's say I had a 15,000 word JSON database of equivalent English and French terms. Or a 12,000 word JSON database of a phonetic transcription of all single syllable English words.

If Wikidata could also specialize in simple useable relational databases, then after I upload my English-French database some one could then add Italian, and Spanish. And pretty soon we could have community access to valuable databases that could be used openly by the community to create lots of cool products and services.

I would really like to see this site become a site that had databases that people could add to and fill-in.

If you search golfball in the English wiki: http://en.wikipedia.org/wiki/Golfball You can see that there is not a Chinese entry. If the relational databases could be set up then a lot of empty non-english wiki entries could be filled using automation.

For example Golf ball only has 14 entries and is minimally world language entry complete But whale shark has more than 50 and is probably pretty world-language-complete for its entry http://en.wikipedia.org/wiki/Whale_shark

And those

Right now I search 'English' and I get this: English Heritage [edit] executive non-departmental public body of the British Government

This is a contextless abstracted datum that then links to the uses of this term in the other wikis. This approach seems limited and more like what the meta-wiki site should be doing as a way to build an interactive backend for the main wiki sites. The only relevant information that is available would be to see how the wiki is itself being used.

This site would be great as a home to user made and edited databases. The site could even be used to generate databases using bad code like this:

var originalWord = $(".input").val() var theNativeLanguage = 'zh'; $('.answerbox p').load("http://"+theNativeLanguage+".wikipedia.org/wiki/"+originalWord+" #mw-content-text ul")

var translatedWord = (derived from method) var myTargetTranslationLanguage = 'en' load("http://"+myTargetTranslationLanguage+".wikipedia.org/wiki/"+translatedWord+" .interwiki-en", function()

People could load and translate: JSON XML Core data SQL

as well as algorithms for data manipulation.

Currently this site seems like this site just tries to be 'wiki's data lite' and not the 'ultimate wiki of data and databases' (which would make this site awesome and more valuable.)

Would this be an impossible expansion in the entirely wrong direction?  – The preceding unsigned comment was added by Mgmoscatello (talk • contribs).

I think they are planning to link wikidata with wikitionary after wikivoyage, maybe then we could use the raw data of wikitionary to do the translation that you are talking about --Napoleon.tan (talk) 02:16, 15 July 2013 (UTC)

Timeline

Am I right that there is no way to use Wikidata with the timeline function in wikipeida? What is a possible solution? Thanks for your thoughts. --FischX (talk) 01:56, 14 July 2013 (UTC)

There might come a time where the timeline extension isn't needed thanks to Wikidata, or at least in the way it's used currently. --Izno (talk) 21:51, 15 July 2013 (UTC)

Upcoming (date), planned events and products

How can I indicate that something has not happened yet? For instance the release of Torment: Tides of Numenera (Q6568802) is planned for 2015, or the strait of Messina Bridge (Q373856) is planned for some day in the future, but it is unclear if some day it will become a reality. Is that already accounted for in the date type?--Micru (talk) 22:37, 15 July 2013 (UTC)

Right now this is not accounted for in the datatype so it has to be made clear by the properties i. e. release date and tentative release date. Something nice to have but most likely very complicated would be to have an flag saying this values was last changed before the date happened. Then you could have only one property.--Livermorium (talk) 01:00, 16 July 2013 (UTC)

Merge items

Could someone copy the labels of Q4219182 to Q2552059 please. The Wikidata interface is such a usability nightmare that I don't know how to do this without spending half an hour changing languages etc. --FA2010 (talk) 08:44, 16 July 2013 (UTC)

  Done. I think you want to take a look at the merge tool. Go to Preferences >> Gadgets >> Wikidata-centric >> Merge (tick the box)! :) ·addshore· talk to me! 08:49, 16 July 2013 (UTC)

RfC:Exclusion criteria in wikipedia namespace

I made RFC about adding more things to Exclusion criteria. Feel free to write your comment in there. --DangSunM (talk) 10:32, 16 July 2013 (UTC)

Konstamonitou-klooster

Hi, I cannot add the Afrikaans article Konstamonitou-klooster to the Wikidata at Q1148615, as somebody created a separate pages for it at Q13035212. Can it be fixed? Thank you. Winstonza (talk) 11:40, 16 July 2013 (UTC)

I have done it for you this time. In future you can merge the item yourself. See Help:Merge --Pyfisch (talk) 11:47, 16 July 2013 (UTC)
Thanks! Winstonza (talk) 11:55, 16 July 2013 (UTC)

Serra and Highland

I want to ask opinion if these two entries should be merged. I am not expert in geology and I do not understand the exact concepts.

Q2735191: Serra (Portuguese), Sierra (Spanish), Serra (Latin)
Q878223: Highland (English)

Torneira (talk) 18:55, 12 July 2013 (UTC)

I thought 'Sierra' had a meaning closer to mountain range (Q46831) but I see that is linked to the the Spanish 'Cordillera'. I thought 'Highland' was closer to 'Planalto' but I see that is linked to plateau (Q75520). Probably best to leave these alone until you get an opinion from someone more familiar with Aragones. Filceolaire (talk) 06:53, 13 July 2013 (UTC)

I'm native speaker of Spanish and Catalan. "Sierra" (ca:Serra) means "mountain range, mountain chain", while "cordillera" (ca:Serralada), is longer/bigger than a "sierra". In fact, it can be considered that a "cordillera" is formed by several "sierras". Instead, AFAIK, a highland is more like a plateau (planalto is Portoguese), es:Meseta, ca:Altiplà, pt:Planalto. So I don't think both items should be merged. Hope it helps! --Quico (talk) 20:20, 17 July 2013 (UTC)

Merge lists

I have previously announced my number merge and my Commons merge lists here. Now I can also announce two new kind of lists:

  • Country merge lists which are similar to the number merge lists, but uses the local name of countries and continents instead of numbers. See the French-English list as the currently only example. This may not work for all languages as it depends on the possibility to find the name of countries unchanged in link titles. Thank you to Pichpich who suggested this kind of report.
  • Category + name merge lists contain items which have links to pages with the same name and same relative position in identical category subtrees in two Wikipedias.

I have tried to make a page which describe all of these list types in one place at Help:Merge lists, but I am unsure of the best name of the page, and even if it should be placed in the Help or Wikidata namespaces. Please comment on the location. And please rewrite the content in better language if you can. I hope that the page will be translated to other languages when the content has become stable.

By the way more kinds of merge lists will probably follow. Suggestions are always welcome, and so are requests for new language combinations for the existing kinds. Byrial (talk) 22:01, 16 July 2013 (UTC)

es-en and es-fr, please. Andreasm háblame / just talk to me 03:54, 18 July 2013 (UTC)
  Done country merge lists es-en and es-fr. Byrial (talk) 09:46, 18 July 2013 (UTC)
I would like to try it. Is it possible for cs-en? Matěj Suchánek (talk) 10:11, 18 July 2013 (UTC)
  Done countrymerge cs-en. Byrial (talk) 11:22, 18 July 2013 (UTC)

Categories

Is it possible to add categories? Makes navigation for readers easier, me seems  Klaas|Z4␟V:  11:25, 18 July 2013 (UTC)

No need to. Similar approach of wikipedia 'Categories' can be done using (adding) the claim 'subclass of' <item> or 'part of' <item>. 139.63.60.122 11:51, 18 July 2013 (UTC)
http://208.80.153.172/wdq/ --Tobias1984 (talk) 12:28, 18 July 2013 (UTC)

Dog breeds

A number of dog breeds are recognized by FCI: http://www.fci.be/nomenclature.aspx Could we have a property (or is there one already?) for matching Q5414 with "Deutsche Dogge (235) (Great Dane)" and/or with the link to the standard (http://www.fci.be/uploaded_files/235g02-en.doc)? --Palnatoke (talk) 12:08, 18 July 2013 (UTC)

Signs and Wonders in the Catholic Charismatic Renewal

How would the experience of more contemporary Catholic writers be included in reference sources, such as books by Dr. Ralph Martin? — Preceding unsigned comment added by 69.250.178.199 (talk)

I don't understand what you are asking. If these writers are judged to be reliable sources then the use of such writers as references for sources is the same as for any other book - create an item for the book and an item for the author (if they don't already exist) then refer to the book item in the 'source' field using the "stated in (P248)" property.
Is that what you wanted to know?. Filceolaire (talk) 18:50, 18 July 2013 (UTC)

Global labels

I am not sure if this has been proposed before (I went missing for a month or so), but while editing items, I've come across several items that could use some sort of global label given that their names/titles rarely vary with the language. For example, most video games would have the same title regardless of the language, and thus having to manually add a label for each language is a tedious and time-consuming task. I think that the same principle could apply for other types of items.

Therefore, I'd like to start this discussion to see what the community thinks of having some sort of global label system that would be used as a label for items with no label defined, or as the default label for non-defined labels on a item. For example, if item Q4921120 has [en] label set to Black Knight Sword, but the rest of the labels are emtpy, we could use the global label to make all the other languages' labels show as Black Knight Sword either, instead of no label listed. Thoughts? — ΛΧΣ21 15:38, 14 July 2013 (UTC)

How is it supposed to be used in the clients? From svwiki-point of view, I think it most often is better to have "no label" rather than a more or less guess by a robot or by somebody who do not speak the language. The problems with empty labels can then be solved by the modules in the clients. (If no sv-label is available, search for any da/nb/nn-label etc, in combination with maintenance-messages and categories.) This, because of the attitude against bots and non-sv-speaking contributions in the project. -- Lavallen (block) 17:06, 14 July 2013 (UTC)
It looks reasonable but I think it's ultimately a bad idea to go in that direction. For one thing, it's good to keep things simple and adding something like a "global label" means one more Help page (and possibly one more guideline). Moreover, it's not that big a hassle to handle this using semi-automatic methods such as scripts that allow more flexibility. Most importantly, the net result of global labels in the short term would be a sharp increase in items with a label but no description and therefore an increase in hard-to-distinguish items. Given the current limitations of the search engine and the auto-complete interface when adding statements, these ambiguously labeled items are a real nuisance. 50.100.140.159 21:52, 14 July 2013 (UTC)
I dislike this idea, because what it ultimately is going to mean is that many people are going to wind up seeing labels in languages they don't understand. That being said, since anything that I could think of that would have a global label would be a proper noun, I think it would make more sense to have a language-independent string property called "name in native language". This would allow, for example, for users to see that Vladimir Putin's name is written as "Владимир Путин" in his native tongue. This, of course, doesn't at all help people understand the name if they don't read the Cyrillic alphabet, but the major issue with a global label is that someone is always going to wind up with something they can't read. It's also worth noting that many infoboxes, at least on enwiki, have a slot for "name in native language" already, so it'd be pursuant to our mission to support this. Sven Manguard Wha? 01:19, 15 July 2013 (UTC)
I think a language fall-through would be better than a global language. Although most people might make English as a throughout language, some people know non-English language only. Also I think there are times when English title for movies are change. For example for titles of games in Japan, they call Resident Evil as Biohazard, or even for movies, they call Fast and Furious 6 as Wild Speed Euro Tour. Even for politically sensitive titles, they sometimes change them. I think they changed the Captain American title in Russia --Napoleon.tan (talk) 02:24, 15 July 2013 (UTC)
See Wikidata:Property_proposal/Pending#Official name / Name / Nom / This is approved pending the availability of the Multilingual text datatype. Filceolaire (talk) 00:37, 16 July 2013 (UTC)

Global descriptions for "Wikipedia disambiguation page" and "Wikipedia category"

Considering the above idea of global labels, I see pro and contra, but what about global descriptions especially for "Wikipedia disambiguation page" and "Wikipedia category"? I think it would be nice to only add a disambig or category "tag" (don't know the technical possibilities), and then the appropriate description is present in all languages. Holger1959 (talk) 07:09, 15 July 2013 (UTC)

Some people even think they could get their own item type, for example "N", like NXXXXX... discuss. Littledogboy (talk) 17:12, 15 July 2013 (UTC)
Isn't this a task for bots? I mean they could get a list of items (eg. from a category) and add the description for any language. Just my thoughts... -- Bene* talk 17:17, 15 July 2013 (UTC)

Maybe I wasn't clear, sorry. I'm not thinking about a new property or an "own item type". I think about descriptions, especially about those that are expected to be always the same in every language. This is the case for Wikipedia categories and for Wikipedia disambiguation pages. Maybe there are other cases, but I don't know more.

I often see items where I type in the standard description "Wikipedia disambiguation page" for English and "Begriffsklärungsseite" for German. Afterwards one bot adds "desambiguación de Wikipedia" for Spanish and "Pàgina de desambiguació" for Catalan. Some days later a second bot adds "doorverwijspagina" for Dutch and seven other translations, then a third bot adds another three translations and so on. After a couple of weeks there are maybe about 30 translations of "Wikipedia disambiguation page", and about 15 translations for "Wikipedia category". Not bad, but how many languages do we support? Over 100, or not?

What I know is that there are standard texts for these two cases (disambig and category), and bots even override descriptions if they don't follow the "rule" (if someone wrote for example "category about tennis in 2009" as description, then it will be changed to "Wikipedia category" by the next bot). I don't know how many disambig items we have, but we have over 2 milliones of Wikipedia category items, if I correctly understand Byrial's table. So why not allow an option to define – by only one edit – "this item is a category", and then the full list of translations of "Wikipedia category" is added to the description automatically and with immediate effect? The same for disambig pages. This would be very very useful and would save so much time! Holger1959 (talk) 20:32, 15 July 2013 (UTC)

I really like this idea. It would save so much effort from all the bots adding it in their own set languages. If, soon after someone typed "Wikipedia category" into a description field, it was automatically translated to all other languages, so much effort would be saved. Del♉sion23 (talk) 23:31, 15 July 2013 (UTC)
We should add instance of (P31) Wikimedia disambiguation page (Q4167410) page as a statement on each of these pages. This would seem to do achieve your objective. Of course you could argue that once this statement is added to a page it would no longer be neccessary to have the description say the page is a Wikipedia disambiguation page. Filceolaire (talk) 23:42, 15 July 2013 (UTC)
Wikimedia disambiguation page (Q4167410) seems not yet used very much. statements are not shown on search, descriptions are. they are also shown at the top of item pages, not like statements at accidental positions (somtimes far down or "hidden" in long lists of statements). with descriptions everyone would see directly what it generally is even if there is no translated label. this is an other point why I think this would be so useful.
Am I right and this idea is a feature request which isn't possible yet? can someone ask or tell the people who better know the technical possibilities? Holger1959 (talk) 00:27, 16 July 2013 (UTC)
Ah. Search. Yes that is a good reason to have 'Disambiguation' in the description as well as in a statement. Filceolaire (talk) 00:55, 16 July 2013 (UTC)
The claim "instance of (P31) Wikimedia disambiguation page (Q4167410)" can be added to every Wikipedia Disambiguation page right now. No waiting required. If you wanted to use some special property like "Type of wikimedia page" then you would have to wait for it to be created. Filceolaire (talk) 00:55, 16 July 2013 (UTC)
For those who do not know what Help:modeling is about, I'll just take this example among others : Ficeolaire I saw other propositions to classify those items, such as making them instance of <ambiguity> among others. There could be a lot of experiements like that, one of the goals of Help:Modeling, in which there is a section for this problem, were to be a central point to communicate to others these kind of propositions we could see in our Wikibase explorations. TomT0m (talk) 11:29, 16 July 2013 (UTC)
But items for Wikipedia Disambiguation pages are not "instance of (P31) Wikimedia disambiguation page (Q4167410)", are they? Littledogboy (talk) 14:11, 16 July 2013 (UTC)

One problem with global descriptions of categories/disambiguations: When somebody move some links to other items, there will be problem with adding label - system will not allow add it because "another item (Q123456) already use label Category:Foo and description disambiguation page for language en". JAn Dudík (talk) 19:08, 17 July 2013 (UTC)

Wish we could move sitelinks together with labels, one-click! Littledogboy (talk) 01:23, 19 July 2013 (UTC)


bot

Please check Liangent-bot has crated many items whit no wikipedia page example [4]79.56.185.3 11:13, 16 July 2013 (UTC)

Per WD:N, this is OK because they're used in statements. --Jakob (Scream about the things I've broken) 11:16, 16 July 2013 (UTC)
Yes but it said that the source is wikipedia 79.56.185.3 11:43, 16 July 2013 (UTC)
See the discussion below Wikidata:Project_chat#Q14000000 ·addshore· talk to me! 10:16, 19 July 2013 (UTC)

Q14000000

is created about statement of some place at china--DangSunM (talk) 00:01, 17 July 2013 (UTC)

this is the problem of Liangent-bot some place... but which one?95.250.193.193 02:09, 17 July 2013 (UTC)
I have added the label for the item. --Wylve (talk) 05:58, 17 July 2013 (UTC)

I tried to update the news with this. Somebody may want to check my work just in case I screwed up. Thanks in advance. TCN7JM 06:04, 17 July 2013 (UTC)

To get it to show correctly on the main page, all I had to do was mark the page (WD:News) for translation. I created Wikidata:News/Editnotice for future reference. The Anonymouse (talk) 06:55, 17 July 2013 (UTC)
Alright. Thanks. TCN7JM 07:00, 17 July 2013 (UTC)
You're welcome. I don't ever remember having to do it in the past, but because of the way the translation is set up, it seems necessary. The Anonymouse (talk) 07:06, 17 July 2013 (UTC)
It would be great to create at least one Wikipedia article about the place.--Ymblanter (talk) 07:16, 17 July 2013 (UTC)
I don't think the village is notable enough for a Wikipedia article. --Wylve (talk) 08:22, 17 July 2013 (UTC)
Then it is not notable for Wikidata, see WD:N.--Ymblanter (talk) 08:39, 17 July 2013 (UTC)
I believe the item satisfies the third criterion of WD:N. I thought Wikidata has lower notability requirements than Wikipedia in general. --Wylve (talk) 09:00, 17 July 2013 (UTC)
It is only used as value for the claim Jiuxian Township (Q11086922) contains the administrative territorial entity (P150) Huangjue (Q14000000). Is there a structural need for that statement? Byrial (talk) 09:31, 17 July 2013 (UTC)
Nobody ever talked of structural need for statements, just for items :) Or you should create notability criterium for statements but that could be a huge waste of time considering the number of statements. I think we should enforce sourcability, there is always a possible usage for geographical informations, they are most probably easily sourcable and make no harm to the database. TomT0m (talk) 09:50, 17 July 2013 (UTC)
As soon as it is sourced with RS, the item becomes notable, at least in the English Wikipedia.--Ymblanter (talk) 10:19, 17 July 2013 (UTC)
And apparently, there are about 700k administrative divisions of China, that means, that they are comparable in average size and population to French communes that all have articles in many Wikipedias. That said, it is certainly easier to find detailed data about French communes than about Chinese subdivisions. --Zolo (talk) 10:25, 17 July 2013 (UTC)
What is really stupid is to source all statements with "imported from Chinese Wikipedia" if no article exists: this means that we have to look in the whole wikipedia to find the information. Better create a property "Google search" to source this kind of information. Snipre (talk) 12:42, 17 July 2013 (UTC)
Can somebody point me to where exactly this village is located? I can find Guang'an, but looking for Jiuxian Township or for Huangjue gives me next to nothing (maybe because I'm using the Roman characters?). TCN7JM 14:11, 17 July 2013 (UTC)
Here http://goo.gl/maps/W6WJ1

Just note that, if Q14000000 is not useful, than we say 14 million plus two item : Gwanyang-dong (Q14000002) --DangSunM (talk) 14:09, 19 July 2013 (UTC)

Items with links but without labels

Can anybody make lists of items, which have link to some lannguage but haven't label in this language? I can update most of them by bot, but I need list with links. e.g for en: 

[[ABC]]
[[Category:foo]]
[[Template:Bar]]
...

If yes, please, make me such lists for dsb, hsb, sk and cs at first. JAn Dudík (talk) 13:30, 18 July 2013 (UTC)

I can do that. Do you really want only the wiki links without language code and without the item numbers? Pr. 2013-07-10 there was 1,127,645 links without a label in same language. Most had zhwiki with 147,094, no 2 was svwiki with 123,215, no 3 was warwiki 83,202, with no 4 was cebwiki with 82,355. Your numbers are: dsbwiki = 58, hsbwiki = 303, skwiki = 1761, cswiki = 1209. Byrial (talk) 17:16, 18 July 2013 (UTC)
Yes, because I'm using script which must have hard-coded language code. Can you make me for start these four lists, please? JAn Dudík (talk) 19:52, 18 July 2013 (UTC)
  Done. Sure, I just had to make sure that I understood the format as I am not used to deliberately making non-functioning links. The lists are at User:Byrial/link_without_label/dsb, User:Byrial/link_without_label/hsb, User:Byrial/link_without_label/sk, User:Byrial/link_without_label/cs. Byrial (talk) 21:25, 18 July 2013 (UTC)
I must copy these lists to file on my computer, so the format is OK. Thanks JAn Dudík (talk) 07:36, 19 July 2013 (UTC)

Importing Iraqi census data

I found Iraqi census data at http://cosit.gov.iq/pdf/2011/pop_no_2008.pdf (Archive) and the idea is something like en:User:Rambot creating U.S. cities with census data, but on the Sorani Kurdish Wikipedia. On en:Wikipedia:Bot_requests/Archive_55#Bot to add articles to the Sorani Kurdish Wikipedia (CKB) about Iraqi cities using census data a user suggested that this data be uploaded here.

What needs to be done to have this data uploaded onto Wikidata to help the creation of these articles?

Thanks WhisperToMe (talk) 19:32, 18 July 2013 (UTC)

Importing this kind of data will certainly be very important, but quantity datatypes will only come this autumn. There is not much we can do for now. --Zolo (talk) 10:45, 19 July 2013 (UTC)

Entering a language code doesn't give the language code but searches for a language beginning with those characters

When I want to add a new page into an item, I usually add the language code, hit tab and paste the page name on that wiki. When I now try to do that, each time I enter the language code, it doesn't give first the language that belongs to that code but start to add languages that start with the characters of the code. Change that back please, it is very very very very much annoying. I estimate that 95% of the additions are added with the language code instead of the language name. So please put the language code in top back again. Romaine (talk) 17:56, 17 July 2013 (UTC)

I'll second that. Littledogboy (talk) 01:20, 19 July 2013 (UTC)
I filed a bug for that at bugzilla:51560. Romaine (talk) 04:56, 20 July 2013 (UTC)

Global Economic Map

Project task force: http://www.wikidata.org/wiki/Wikidata:Global_Economic_Map_task_force

The Global Economic Map is a proposal for a new Wikimedia Foundation Sister Project. Every country, every administrative region and city in the world will have their own article with a standard data set of economic statistics. The data used in this project is from government publications, SEC data, and other professional sources. Here is a link to the project: https://meta.wikimedia.org/wiki/Global_Economic_Map

This is our plan for Wikidata integration:

  1. Wikidata already has a page on each country.
  2. Wikidata already has a page on each administrative division of each of these countries.
  3. Wikidata already has a page on each of the larger companies and financial institutions.
  4. The Global Economic Map project will work with Wikidata to define the additional items and properties needed to incorporate the Global Economic data into Wikidata in a form which is machine readable.
  5. Once the Wikidata development team have completed the development of the datatypes required for this project (notably the URL datatype and the Number with Dimension datatype - both due to be completed by September 2013)[5] then the properties can be created and the Global Economic Map project will work with Wikidata to create bots to automatically import data from various databases into the various pages in Wikidata. Each datum will be a separate statement on wikidata with a source (where it came from, when it was downloaded) and appropriate qualifiers (industry sector, time period it refers to, location). Where automation is not practical the data will be imported by hand into Wikidata, including the source and date info.
  6. Wikidata will make this data, like all the data on Wikidata, available, through their public API, in various standard formats, so it can be reused by others.
  7. As part of Wikidata stage 3 (due autumn 2013) the Wikidata developers will work on creating queries and data visualisations using the data in Wikidata. The Economic World map team will create a mini standalone site where the economic data can be queried and displayed in various ways.
  8. The Global Economic Map team will work with the Wikidata stage 3 developers and one of the wikipedias (probably not the English Wikipedia - their articles are pretty stable so they don't want too much experimentation) to create data visualisations using the data on Wikidata and add this to national and regional wikipedia pages. Once these are stable they can be adapted to other nations and regions on that wikipedia. These can then be be used as a model by other wikipedias.

Mcnabber091 (talk) 04:14, 19 July 2013 (UTC)

It's time to start a new Task force? --ValterVB (talk) 19:16, 19 July 2013 (UTC)

Featured Entity

Hello

I have problem with metro stations and I see that this is bigger problem on WikiData. Some time ago I was trying to mark metrostations. But I see a difference between Q4889339 and Q11733754. One have combination Property:P31 -> Q928830, and second have Property:P168 -> Q928830. And I am not sure what is correct.

Is there any place when I can find something like "Featured Entity", where I will be able to compare what I am doing with examples, what were check by couple wikidatians (?).

I made quite a lot of edits about warships (~150k on pl.wiki). Can somebody show me example of correctly described warship on Wikidata, so I can copy this set of properities to other entity? Or use as example Q2876572 and tell me what is wrong and how it should look? PMG (talk) 15:06, 19 July 2013 (UTC)

This is something we really need (although it's worth noting that for people from English Wikipedia, "featured" carries a bit of a different connotation). Sven Manguard Wha? 20:02, 19 July 2013 (UTC)
Help:Example items? Help:Example entities? --Izno (talk)
Tom recently started Help:Modeling which is an important task but a daunting one. Perhaps a better first step is to pick a handful of examples (one music biography, one movie, one album, one political party, one company) and decide as a community to collectively work on these and showcase them. It's easier to get people involved in the process and it's also easier to make modeling decisions when things aren't simply discussed in the abstract. Pichpich (talk) 21:27, 19 July 2013 (UTC)
I agree that more examples would be good. There are relevant examples that attempt to tease out some of the subtle differences between instances and classes in the documentation atop Property_talk:P31 and Property_talk:P279. Help:Basic membership properties also gives examples and detailed explanations of use cases for those properties -- warships included! Emw (talk) 00:23, 20 July 2013 (UTC)

Where and why quick-link for adding new page is gone?

It was very useful when after creating new page at Wikipedia you could just click "add iw" and quickly interconnect them. Now one needs to go to other wikipedia then open a wikidata page and manually add the link. Not "user-friendly" at all.. Hugo.arg (talk) 09:51, 19 July 2013 (UTC)

It works again. Sorry. Hugo.arg (talk) 09:54, 19 July 2013 (UTC)
Thanks for reporting! As you noticed this should now be fixed! :) ·addshore· talk to me! 10:09, 19 July 2013 (UTC)
I think this is not working. When clicking on add, one gets the blue box for the language, but not the second blue box for the name of the article in that language. Also no active save button. Hobbema (talk) 07:21, 20 July 2013 (UTC)
Can you give a link to where this is happening? which browser are you using? Cheers Aude (talk) 07:47, 20 July 2013 (UTC)
It is happening everywhere. I am using Firefox 22.0 on Windows 7. Hobbema (talk) 08:08, 20 July 2013 (UTC)
Do you mean when editing items on wikidata? or the widget on Wikipedia for connecting pages to wikidata? (the widget has no blue box, afaik, but editing items on wikidata does) Aude (talk) 11:23, 20 July 2013 (UTC)
You might also need to bypass your cache (see w:en:Wikipedia:Bypass_your_cache#Firefox_and_other_related_browsers) to get the javascript to refresh. I have seen old javascript with a few pages and in that case they only work when I bypass my cache. Aude (talk) 11:55, 20 July 2013 (UTC)

m:Wikidentify

Would this be possible to do based on Wikidata info/queries? Currently, for example, Wikidata has no 'color' property for the apple item, or for specific cultivars. So do we need to start a new database for identification? πr2 (t • c) 13:57, 20 July 2013 (UTC)

Wikidentify is a fantastic idea, and yes, I think it would be possible to do with Wikidata properties and queries. Folks from the Wikidata taxonomy task force would likely be interested by this. We actually do have a "color" property: color (P462) -- you can search for other properties using the form in Wikidata:List_of_properties. Cheers, Emw (talk) 14:11, 20 July 2013 (UTC)
Great! Thanks for the response. I'll ask there too. πr2 (t • c) 14:14, 20 July 2013 (UTC)

"edit" instead of "save / cancel"

 
Series of pictures showing the bug.

At moment I've got edit problems as long as I'm logged on. I start entering a statement by clicking "add", then I can type in a property and a value. But the link on the right site shows "edit" instead of "save / cancel" and I can proceed. When I press the link, it changes to "save / cancel". The issue occurs on IE10 and Chrome, no matter which item I'm editing. When I'm not logged on, it works fine. --Nightwish62 (talk) 20:34, 16 July 2013 (UTC)

Deleting cache, restarting computer or even change the computer doesn't help too. Ok, no more statement-edits as long the issue exist. --Nightwish62 (talk) 11:22, 17 July 2013 (UTC)
Having the same issue. --Tobias1984 (talk) 09:09, 18 July 2013 (UTC)
I don't seem to be able to reproduce this. Which entity are you using and what exactly are you adding as the statement property and value? ·addshore· talk to me! 10:14, 19 July 2013 (UTC)
It happens on all the items I try to edit, but not when I'm logged off. I tried it on Firefox (22) and Chrome (28). --Tobias1984 (talk) 11:04, 19 July 2013 (UTC)
I just deactivated all my gadgets one by one and removed everything from my common.js file. Still doesn't work. --Tobias1984 (talk) 11:13, 19 July 2013 (UTC)
Still cant reproduce :/ Which entity are you using and what exactly are you adding as the statement property and value? ·addshore· talk to me! 12:35, 19 July 2013 (UTC)
Not sure what you mean with entity. But when I edit Q4957936 and press "add" under the headline "Statements" then the box shows the input field for "property" and to the right I only see "edit". When I do the same thing not logged in, I see the input field and "save cancel" to the right. --Tobias1984 (talk) 13:09, 19 July 2013 (UTC)
I can't reproduce this on the same item with the same browser, see File:Wikidata_adding_a_statement.png. It must be down to some sort of javascript cached / mess up. Have you really tried everything listed above? ·addshore· talk to me! 13:36, 19 July 2013 (UTC)
I tried it on two computers now. Same problem on both machines. --Tobias1984 (talk) 21:06, 19 July 2013 (UTC)
To be honest, I'm glad I'm not the only one which struggles with this bug. It's 100% like Tobias described, even the part that I've to refresh before I would be able to add a source. As said: No matter of item, property, value, computer that I used, it's something within my account settings. One thing: Right before the issue occur the first time, I had changed my language settings in Wikipedia. The reason was, every site I loaded on the german Wikipedia brought up a small popup "Geändert von Deutsch" (or something like that) on the cog of the left navigation pane. This was annoying so I played around with my language settings. I think it was "Schweizerdeutsch" before and I changed it to German. Maybe this has caused the problem here in Wikidata, so I already tried to restore my original settings, but the issue here still exist. --Nightwish62 (talk) 18:23, 20 July 2013 (UTC)
Ok, it seems that 'restore my defaults' here in Wikidata solved the probled. Could you try this also, Tobias? --Nightwish62 (talk) 18:29, 20 July 2013 (UTC)
That actually worked. I wonder what the bug was :/ --Tobias1984 (talk) 18:43, 20 July 2013 (UTC)
Yes, this maybe solved our problems, but we still don't know what's the problem caused. At least we know it's a user setting issue. I suggest the next one which has the problem don't use the reset function and take contact to the development team. --77.239.41.207 19:29, 20 July 2013 (UTC)
This is a problem with the UniversalLanguageSelector extension. I'm not sure why it only occurs for some people, but here is the solution: open the ULS (by clicking the language next to your username on the top right of the page), choose "input settings", choose "input" from the left list and check for every language listed under "language used for writing" that one of the input methods is selected. Tobijat (talk) 11:11, 31 July 2013 (UTC)
In my case the problem is still going on! In the meantime almost the field for the modification reappears, but it doesnot help as the modification cannot be saved as long as I am logged in. As soon as I am logged out the modification can be saved! The problem still needs to be resolved. I do not know how many user are affected by this same problem, but I am not the only one!DidiWeidmann (talk) 16:45, 7 August 2013 (UTC)

Dead links supporting the text -- Links go nowhere

http://en.wikipedia.org/wiki/Bill_Ayers_presidential_election_controversy — Preceding unsigned comment added by 174.96.54.144 (talk)

What does this have to do with Wikidata? The Anonymouse (talk) 17:48, 20 July 2013 (UTC)
Perhaps he/she found the "Edit links" button... -- Bene* talk 21:25, 20 July 2013 (UTC)

Wikivoyage notability

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There are clear consensus to adding that. So I will change WD:N.--DangSunM (talk) 09:13, 21 July 2013 (UTC)

I am proposing changing the notability policy from "It contains at least one valid sitelink to a Wikipedia page." to "It contains at least one valid sitelink to a Wikipedia or Wikivoyage page." to prepare for Monday's deployment of Wikidata links to Wikivoyage. --Rschen7754 23:52, 15 July 2013 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Question

Hello,

I have a question regarding linking pages that have two entries for example:

  • Hr. Ms. K XI for the Dutch page and HNLMS K XI for the English and Hungarian page
  • SMS Zieten for the German and Polish page and SMS Zieten for the English page

How can these pages be linked or merged?

Kind regards,77.250.231.214 21:00, 20 July 2013 (UTC)

You can merge them either manually or automatically. There are instructions at Help:Merge :) Del♉sion23 (talk) 21:49, 20 July 2013 (UTC)
thx 77.250.231.214 11:43, 21 July 2013 (UTC)

Animation voice actor in a different language release

Hello. In Futurama: Bender's Big Score, the character of Fry is voiced by Billy West. But in the Italian version, Fry is voiced by Fabrizio Manfredi. I can add a statement for cast member Fabrizio Manfredi and a qualifier for role Fry, but there should be another qualifier saying it was in the Italian release of the film. What qualifier property? Or should there be a whole separate item for the Italian release of Futurama: Bender's Big Score, with all the Italian voice actors? Jefft0 (talk) 22:58, 20 July 2013 (UTC)

That (a whole new item) or you add two cast member for Fry, something like :
Statement one:
cast member <Billy West>
  • version <Original>
  • role <Fry>
Statement two:
cast member <Fabrizio Manfredi>
  • version <Italian>
  • role <Fry>
I'm not sure I would not prefer the new item solution as it is consistent with what we already do with books and editions, and it allows to make a precise statement, for example if you want to cite what Fry says in Italian (although it is unlikely to be a source ;) ). But a little help from the interfaces would help in that case, as in books. TomT0m (talk) 08:05, 21 July 2013 (UTC)

Can someone please create this property?

Wikidata:Property_proposal/Term#Encoded_by has had unanimous support for over a week. Its unavailability is blocking data modelling work at WT:MBTF. Could someone please create that property? Thanks, Emw (talk) 12:04, 21 July 2013 (UTC)

  Done: Property:P702 --Paperoastro (talk) 12:24, 21 July 2013 (UTC)

Roadmap for deploying Monolingual text

I was just looking at the [roadmap for Wikidata] and noticed

  • url datatype to be available in July
  • quantity datatype to be available in September
  • Multilingual text datatype availability not listed
  • Monolingual text datatype availability not listed

At the moment the only Pending property with Multilingual text datatype is the Sandbox property so that may not be missed. There are however 2 Pending properties with Monolingual text datatype. What is happening with this datatype? If this datatype is not going to happen then tell us. We can create these properties with string datatype and specify the language in a qualifier and we don't need to delay any more. Filceolaire (talk) 22:47, 18 July 2013 (UTC)

Boolean datatype and Geoshape datatype availabilities also not listed. Filceolaire (talk) 23:11, 18 July 2013 (UTC)

They have expressed that Boolean won't be happening, from memory. --Izno (talk) 23:26, 18 July 2013 (UTC)
That's odd. Surely the Boolean datatype is the simplest to implement so this would be a deliberate choice of design. Any idea why we'd want to avoid it? 02:35, 19 July 2013 (UTC) — Preceding unsigned comment added by 50.100.140.159 (talk)
It's anyway easy to do with one 'True' and one 'False' items which already exists. However I'm not convinced it's a very useful thing right now. TomT0m (talk) 09:01, 19 July 2013 (UTC)
I can see the advantage of a boolean in other places, but it isn't a very semantic thing. We really have to try to make most statements with item-properties so the items are connected to each other. An extreme example would be to add the statement "is duck (boolean) = false" to 12 million items ;). --Tobias1984 (talk) 09:23, 19 July 2013 (UTC)
en:Open_world_assumption vs. en:Stable_model_semantics#Closed_world_assumption (might not be the best article /o\ ) :) TomT0m (talk) 09:38, 19 July 2013 (UTC)
Yes, why we should wait for something which maybe never happens. I think we should use qualifier to specify the language. In worst case we've to run a bot which converts the statements to the monolingual data type later. --Nightwish62 (talk) 18:47, 20 July 2013 (UTC)

Monolingual is definitely still on. Denny just forgot to add it to the roadmap. I asked him to fix that. For multilingual: Me poking about this now actually started a discussion if we still need that. If you have specific usecases for that please let me know and I'll bring them up. --Lydia Pintscher (WMDE) (talk) 13:31, 22 July 2013 (UTC)

Yet another merge list type

The regulars here may used to me announcing a new type list of items which maybe can be merged. Now I do it again: The two substring merge lists contain pairs of different items with links that contain two common substrings in a pattern which are linked together by some other model item. There is from the start three lists: albums (with common substrings for album title and artist), songs (with common substrings for song title and artist) and footballers (with common substrings for footballer and birth year). Please tell if you have ideas for more two substring merge lists; I will need a start pattern and start Wikipedia. Byrial (talk) 19:21, 21 July 2013 (UTC)

Wow, you got it working, well done :D Looks great! Del♉sion23 (talk) 19:56, 21 July 2013 (UTC)

"Add links" option in Wikipedia and RfDs

Hello, I have a suggestion. If we have 2 articles in Spanish and English Wikipedia for example, each with their own Wikidata item, and we link them by clicking "Add item" at the left panel of "Languages", then they merge, but it's not created a Request for Deletion. That's different than merging items using Gadget-Merge.js, which makes a RfD (besides Edit conflicts). Maybe it can be added that gadget to that way of merging items. Greetings :) --UAwiki (talk) 07:46, 22 July 2013 (UTC)

Language code for Chinese labels (zh?)

I was wondering what would be the standard language label for chinese character on Wikidata? I notice that for item that were updated by importing wikilinks to label, they place them to zh. But for items created by Lianget-bot, they import the label for zh-cn. see example Q13449442. I am thinking that we should use zh language code rather than the zh-cn.

Also, what type of chinese character would be saved should it be traditional chinese or simplified chinese? Or either?

--Napoleon.tan (talk) 10:37, 22 July 2013 (UTC)

Question

Is there a property that can be used to source statements with sources that do not have items (imported from Wikimedia project (P143) and stated in (P248) both seem to have the item datatype). Thanks, --Jakob (Scream about the things I've broken) 11:20, 22 July 2013 (UTC)

No. For reusability reasons we use item as main sources and this will force to use high quality references which can be used several times instead of sources which can be used only once. But can give the case of the source you want to use ? Snipre (talk) 11:43, 22 July 2013 (UTC)
this, for adding contains the administrative territorial entity (P150) information to town/borough/township items. --Jakob (Scream about the things I've broken) 11:59, 22 July 2013 (UTC)
How about stated in (P248): 2000 United States Census (Q166998)?  — Felix Reimann (talk) 13:57, 22 July 2013 (UTC)
This a part of the US Census 2000 documents (if you look at the pdf you will see at the begining Appendix F as title, so this is a part of a more general document). So this should be definitively an item in wikidata: find the report containing these files and create the corresponding item for the report (and not for each map or state). It is quite complex to understand the data structure and how the data were published. Better ask the census bureau how to cite their documents (see here. Snipre (talk) 14:26, 22 July 2013 (UTC)
@Felix Reimann This is not enough: the maps are part of a report which is part of 2000 United States Census (Q166998). We have to find the name of the report and create an item for it. See report in Help:Sources and in that case you can add the property "part of" with 2000 United States Census (Q166998) as value. Snipre (talk) 14:29, 22 July 2013 (UTC)
As I understand the data structure the pdf files are part of State/County Subdivision Outline Maps which are part of Reference maps which is part of 2000 United States Census (Q166998). If we can simplify that in on source this will be good. Snipre (talk) 14:41, 22 July 2013 (UTC)
See here for an example of citation or there. Snipre (talk) 14:47, 22 July 2013 (UTC)
New item with: P357 (P357):State/County Subdivision Outline Maps, author (P50): United States Census Bureau (Q637413), original language of film or TV show (P364): English (Q1860), publication date (P577): June 28, 2005, publisher (P123): United States Census Bureau (Q637413), language of work or name (P407): English (Q1860), part of (P361): 2000 United States Census (Q166998), P107 (P107): work (Q386724), instance of (P31): technical documentation (Q1413406), place of publication (P291): Suitland Snipre (talk) 14:57, 22 July 2013 (UTC)

  Done: State/County Subdivision Outline Maps (Q14177941)

Rename "task forces" to "project"

The first "task forces" had more or less one-off goals like adding labels to the first 1000s items, but now most of them have much wider and more durable goals (see Category:Task forces). I propose to rename them to "Project" or "Wikiproject" as the word task force does not really apply for that. It would be more consistent with other Wikis. Plus, the term "task force" seems to suggest it should be managed by a small group of insiders, which is a really awkward connatation. --Zolo (talk) 08:46, 9 July 2013 (UTC)

Projects or task forces in Wikidata will be managed by small teams in any cases. For me the name is not important. Snipre (talk) 09:21, 9 July 2013 (UTC)
It might be helpful for new users if it is more consistent with the rest of Wikipedia. --Tobias1984 (talk) 09:51, 9 July 2013 (UTC)
  Oppose Other Wikimedia projects use different terms; also, Wikidata:Roads task force has a large number of subpages that would create a mess if they were to be moved. --Rschen7754 10:04, 9 July 2013 (UTC)
Sorry, but I do not understand your point. It is not just that "project" is used in most major Wikipedias, it is also that "task force" is a bad name. And a bot can fix links, why would that create a mess ? --Zolo (talk) 13:09, 9 July 2013 (UTC)
I would support renaming, but don't know what would be the best name. Task forces is also hard to translate for other languages. --Stryn (talk) 10:46, 9 July 2013 (UTC)
There is also the portail / project duality in Wikipedia. Should we have that here too ? I do not think so, but that is because I do not see the point of portals anyway. I would vote for "project", as it is simple and already in use. Wikidata is not very simple to use, and I would say we should avoid adding useless specificities. --Zolo (talk) 13:09, 9 July 2013 (UTC)
  Support Seems reasonable. Silver hr (talk) 23:52, 11 July 2013 (UTC)
  Support --Tobias1984 (talk) 12:43, 12 July 2013 (UTC)
  Oppose Do we really need to do this? There are more important things to take care of. — ΛΧΣ21 17:57, 12 July 2013 (UTC)
Sure enough it is not terribly important, but it the quicker we do it, the less work changes we need. --Zolo (talk) 08:12, 16 July 2013 (UTC)
  Support. Ayack (talk) 08:38, 16 July 2013 (UTC)
  Support. Task force isn't the easily word for not English speaker, and the litteral translation in french is atrocious (Wikidata:Forces opérationnelles). It have a temporal and intensive sens. For me a Project/Task force is a page where we can talk about a thematic problematic in a long run, because Wikidata:Requests for comment is for temporal discussion and the rule and help pages are translated so their discussions are spitted. --Nouill (talk) 19:16, 16 July 2013 (UTC)
  Support per Zolo's rationale. I prefer "WikiProject" (note capitalization) to "Project", since that's the name for this kind of thing on Wikipedia. These groups are effectively those, except on Wikidata. Emw (talk) 02:58, 17 July 2013 (UTC)
  Support - I like Zolo's reasoning. TCN7JM 03:01, 17 July 2013 (UTC)

I requested renaming at Wikidata:Bot requests#Rename "task force" to project". --Zolo (talk) 20:22, 22 July 2013 (UTC)

Criterion 2 of WT:N

Your input is requested at WT:N#Criterion 2. Thanks. --Izno (talk) 00:12, 23 July 2013 (UTC)

There is also a contested deletion related to this that requires discussion. Please see Wikidata:Requests_for_deletions#Q14178918. Del♉sion23 (talk) 08:23, 23 July 2013 (UTC)

Hong Kong

Hey :)

Denny and Legoktm are going to give a talk at this year's Wikimania about the state of Wikidata from the development and community side. It'd be really really awesome if you could help fill in information related to Hong Kong (the place where Wikimania is going to take place) so that they can show some fancy maps and other visualizations like the ones at https://dl.dropboxusercontent.com/u/172199972/map/index.html (Also click through to the interactive map there.) Useful things could be public transport stations, the districts, buildings that are noteworthy and more. This would be a cool opportunity to wow the audience there. --Lydia Pintscher (WMDE) (talk) 10:57, 23 July 2013 (UTC)

howto change Talk:Q3568027

howto change Talk:Q3568027

  Done Del♉sion23 (talk) 11:14, 23 July 2013 (UTC)

Pywikipedia is migrating to git

Hello, Sorry for English but It's very important for bot operators so I hope someone translates this. Pywikipedia is migrating to Git so after July 26, SVN checkouts won't be updated If you're using Pywikipedia you have to switch to git, otherwise you will use out-dated framework and your bot might not work properly. There is a manual for doing that and a blog post explaining about this change in non-technical language. If you have question feel free to ask in mw:Manual talk:Pywikipediabot/Gerrit, mailing list, or in the IRC channel. Best Amir (via Global message delivery). 13:56, 23 July 2013 (UTC)

Official name property

The 'Official name' property has been approved but is on hold waiting for the availability of the multilingual text datatype.

During the discussion I called for the datatype to be changed to monolingual text datatype and of those who commented on this change agreed. When the proposal was moved to Wikidata:Property_proposal/Pending however it was with the multilingual text datatype.

The existing discussion is at Wikidata:Property_proposal/Pending#Official name / Name / Nom /.

Does anyone object to moving this to monolingual text datatype? Filceolaire (talk) 00:45, 16 July 2013 (UTC)

I proposed the property and moved it in pending. Probably I did not correctly interpreted the consensus, between multi- or monolingual text datatypes. I have not anything against the change to monolingual. --Paperoastro (talk) 07:54, 16 July 2013 (UTC)
Changed to Monolingual text datatype. Filceolaire (talk) 18:58, 18 July 2013 (UTC)
Sorry if this is too late, but what if an entity has official names in various languages (like the UN)? --Wylve (talk) 07:07, 23 July 2013 (UTC)
Have a separate statement for each name with appropriate qualifiers (Language, Start Date, End Date etc.) Filceolaire (talk) 00:53, 24 July 2013 (UTC)
That is common also in Sweden. There is often an official Swedish name and an official English name, and before WW1, it was common with official French names. I guess that is also true in multi-language-countries. -- Lavallen (block) 07:21, 23 July 2013 (UTC)
I also wonder what the reasoning is to make this a monolingual-text. How is this property otherwise going to work for cases like Ljubljana (Q437) where the official name and language change? The name has to go back and forth from Ljublijana to Laibach a couple of times. Plus we have to find a better definition of official. I think of official as "Approved by authority" ([6]). Who was the authority and what was the official name of Ljublijana during the 1943–1945 occupation? For the occupation forces Laibach and for the inhabitants Ljublijana? Who is more official? --Tobias1984 (talk) 08:57, 23 July 2013 (UTC)
Having a separate statement for each with appropriate qualifiers is better than having a multilingual property with no qualifiers. Filceolaire (talk) 00:53, 24 July 2013 (UTC)
Yes, tricky, Stockholm Municipality prefer to call themself Stockholm City, it's the "official name" according to the municipal authorities. But the Swedish goverment have not given them any other name than Stockholm Municipality. -- Lavallen (block) 09:39, 23 July 2013 (UTC)
Give both with appropriate sources. Argue over which is ranked as the preferred name. Filceolaire (talk) 00:53, 24 July 2013 (UTC)
With Monolingual datatype you can list as many Official names as you can find sources for and each can have qualifiers for Language, Start Date, End Date etc.
With Multilingual datatype you are inviting editors to enter names in a hundred different languages whether or not an official name in that language was ever established and there is no place to give each name it's own source or qualifiers. Filceolaire (talk) 00:43, 24 July 2013 (UTC)

Image for the main page?

What is everyones opinion on adding an image to the main page? Many other projects do this already! I was thinking a weekly image / visualisation displaying some of the data that is stored on wikidata? I have seen some really nice ones out there! :) ·addshore· talk to me! 10:56, 17 July 2013 (UTC)

  Support but only for graphs based on reasonably sourced information. --Tobias1984 (talk) 10:59, 17 July 2013 (UTC)
  Support for images based on sourced information to start when we are sure to have enough good images. Byrial (talk) 11:05, 17 July 2013 (UTC)
  Support for images relating to data, such as graphs and whatnot. TCN7JM 13:36, 17 July 2013 (UTC)
  Support --Chrumps (talk) 13:40, 17 July 2013 (UTC)
  Support, Conny (talk) 14:42, 17 July 2013 (UTC).
  Support --دوستدار ایران بزرگ (talk) 16:58, 17 July 2013 (UTC)

  Support  Klaas|Z4␟V:  11:19, 18 July 2013 (UTC)

  • Great! :) There are so many great images that we can select from a single visualisation, especially the map which I hope you have all seen. I will setup a page for the 'Visualization of the week'? (Or should we just call it 'Image of the week'? :). Once the page is up we can plan and discuss further potentially getting some ideas queued up! ·addshore· talk to me! 08:04, 18 July 2013 (UTC)
I can appreciate adding an image, but please don't do anything so heavyweight as En.Wiki or even Commons. The types of images we should have would be more to the tune "hey, we think this is a cool way to see things" and not an example of "this is the best way to view things". --Izno (talk) 16:25, 18 July 2013 (UTC)
I think a good idea would be to automatically generate a graph of the data stored on Wikidata that shows the relations between items and other items. Of course, since we pretty much only have interwiki links right now, it wouldn't really work, but once we have relational data about all kinds of things, we could generate visualization of the data and the links between nodes of data, and show that on the main page. What would be even more interesting is to make it navigable. It'd be, in a way, a map of a part of the data stored on Wikidata, and we could change regularly from one map to another. -- Rastus Vernon (talk) 06:10, 20 July 2013 (UTC)

Wikidata:Database reports/Constraint violations/P17

The reports lists lot of "one of" violations. No wonder as it accepts only real world countries, non fictional. So e.g. District 12 (Q14136664) would end in a violation. I think we've those options:

  1. Don't change anything: So the list would get bigger and bigger
  2. Change the constraint violation rule (if possible?), so it accept the existing "one of"-values and in addition all items which has an "instance of:fictional location"-statement. Even it is in my opinion the best way, I don't think this is technical possible, because it need a 'subquery' for each item to check it is an fictional character
  3. Remove the 'one of' constraint at all
  4. Also add fictional countries to the list of valid values

Please vote or comment. --Nightwish62 (talk) 10:51, 22 July 2013 (UTC)

The property is defined and was proposed as "sovereign state of this item". Thus, delete all claims which do not point to a valid state. In 90% of the cases the claims were set by too dumb bots which do not recognize that the item is fiction.  — Felix Reimann (talk) 15:16, 22 July 2013 (UTC)

  Comment As for the example, it wasn't a dumb bot, but me who makes the claim. So only if something is fictional, it doesn't mean it doesn't fulfill the requirement of "sovereign state of this item", because e.g. Panem is a valid state within the The Hunger Games universe (Q748351). It's the same as Katniss Everdeen (Q2071301) has the sex female. Or what do you think we should do? Create one fictional property for each 'realworld property'? 'fictional sovereign state of this fictional item' or 'fictional sex of this fictional character'? --Nightwish62 (talk) 16:02, 22 July 2013 (UTC)
Ups, one of the 1% other cases, sorry! :) This has to thoroughly discussed and is a result of ambiguous property proposals and definitions. I see two possible use cases for this property:
  1. As a link for most geographic entities to the state they belong to. In this strict sense, everything which is not a recognized state as defined, e.g., by the UN, should be removed (fictional states, historic states, Korea->S/N Korea, ...)
  2. In a wider sense, everything which someone calls or has called a "state".
In my opinion, special properties should have an as strict sense as possible. This allows the most generic reuse (for example: "a thing is in a state, thus i can get it's top level domain" (stupid example, please improve)). For uses in a wider sense, instance of (P31) and friends are available. For example, you could create an item "State in the Hunger games" where your item is instance of. The new item itself could be "part of" Hunger Games and instance of "fictional state" like also Gotham City (Q732858) or Gondor (Q213586). However, no matter how you decide, it should be throughly documented on the properties talk page.  — Felix Reimann (talk) 17:39, 22 July 2013 (UTC)
Sorry for changing to German, but for better understanding I'll do this step as Felix Reimann also has German as native language and my English isn't that good for deeper discussion.
"This has to thoroughly discussed and is a result of ambiguous property proposals and definitions" --> wo genau finde ich diese 'gründliche Diskussion'? Ich ärgere mich schon längers, dass bei der Erstellung einer Eigenschaft nur der ursprüngliche Vorschlag, ohne die stattgefundene Diskussion kopiert wird. Genau für solche Fälle wäre es wichtig auch die Diskussion mitzukopieren. Ich hab mir jetzt nicht die Mühe gemacht das Archiv zu durchsuchen. Was die Diskussionsseite unter der Eigenschaft selber betrifft (Property_talk:P17) sehe ich jedenfalls keine Diskussion die sich mit der Thematik fiktionaler Länder beschäftigt. Deinem Beispiel es über die "ist eine Instanz von" zu lösen, konnte ich soweit folgen (interessanter Ansatz übrigens). Bringt aber meiner Meinung nach nur Nachteile. Erstmal ist es gerade bei den Tributen von Panem besonders sinnlos, da Panem der absolut einzige Staat ist der namentlich bekannt ist und daher nebst dem Staat an sich noch dieses 'Über-Objekt' erstellt würde. Zweitens würde es bedeuten, dass für jedes fiktive Werk ein solches Objekt angelegt werden muss, was locker einige tausend wenn nicht zehntausende zusätzlicher "Land aus ..."-Objekten bedeuten würde. Kleines Detail welches mir nebenbei gerade aufgefallen ist: "State in the Hunger games" als eine Instanz von "fictional state" zu verlinken wäre übrigens falsch, soweit ich es verstanden habe wäre korrekt "ist eine Unterklasse von".
Einer der Hauptgründe der für mich jedoch dagegen spricht, ist die absolut komplizierte und inkonsistente Suche. Ich habe keine Idee wie die Suchmöglichkeiten in Zukunft aussehen werden, aber von einer Suchmaske erwarte ich bei einer Suche von "liegt im Land XYZ" die Resultate subnationaler Orte, unabhängig davon ob es fiktiv ist oder nicht. Zudem dürfte die Suchperformance einiges schlechter sein, Objekte zu finden die ein "<ist eine Instanz von> Staat in %fiktives Werk/Universum-Name%"-Statement haben, welches Objekt selber wiederum eine Subklasse von "fiktiver Staat" ist. Auf der anderen Seite hingegen, sehe ich überhaupt keine Nachteile die Eigenschaft "Land" auch für fiktive Länder zu verwenden. Einzig der Violation-Bericht sollte angepasst werden, denn sonst bringt er uns gar nichts. Ansonsten werden diejenigen abgeschreckt, welche gemäss dem Violation-Bericht Korrekturen vornehmen möchten und ständig auf fiktive Staaten treffen. Darum ja meine ursprüngliche Anfrage/Idee, ob es möglich wäre die Logik so zu ändern, dass es nebst der Liste gültiger Werte alle Objekte die fiktive Staaten sind ausschliesst.
Ansonsten stehe ich zu meiner Meinung, dass die von dir sogenannten Spezial-Eigenschaften auch immer für die echte wie fiktive Welt verwendet werden sollte. Während Item-Typen sich noch über die von dir vorgeschlagene Lösung handhaben liesen, ginge es bei anderen Datentypen nicht mehr. Wie willst du das Geburtsdatum einer fiktiven Person erfassen? Ich hoffe wir sind uns einig dass die denkbar ungünstigste Lösung die ist, dass einmal mit fiktiven Objekten speziell gehandhabt wird (eigentlich vorhandene Spezial-Eigenschaften wie eben "Land" wird nicht verwendet, sondern über eine Instanz-Von-Lösung) und ein anderes Mal normal (z.B. Geburtsdatum von fiktiven Charaktere direkt die Eigenschaften "Geburtsdatum" verwendet wird). Für eine spätere Abfrage/Suche wäre diese Inkonsequenz der Horror. --Nightwish62 (talk) 22:28, 22 July 2013 (UTC)
Da fehlt ein "be" :( Es sollte dokumentiert sein, ist es aber nicht. Da dies eine sehr früh eingeführte Eigenschaft ist, ist die Definition ziemlich wischiwaschi. So wie es aktuell definiert ist, ist P17 für heutige, anerkannte Staaten gedacht. Wenn also ein Objekt per P17 verlinkt ist, kann man davon ausgehen, dass es all die Eigenschaften hat, die typisch für heutige Staaten sind, siehe bspw. de:Vorlage:Infobox Staat. Und Vorwahlen u.ä. oder eine Geokoordinate ist für Panem unbekannt. Wie gesagt, ich bin weder von der Definition von P17 noch von dem Nutzen dieser Eigenschaft überhaupt überzeugt. Jedoch: Ich bin durchaus der Meinung, dass du located in the administrative territorial entity (P131) verwenden kannst. Also z.B. District 12 (Q14136664) located in the administrative territorial entity (P131) Panem (Q10615930). Und Capitol located in the administrative territorial entity (P131) District 12 (Q14136664) (keine Ahnung ob das Beispiel richtig ist). Leider würde dies auch zu Constraintverletzungen bei P131 führen. Da die Liste der Cosntriantverletzungen >30000 ist, würde ich das mal riskieren. Bei der Diskussion zur Aufweichung der "muss ein Staat sein"-Constraints auf P131 unterstütze ich dich gerne.
Ich kenn mich wie gesagt in Panem nicht aus. Wenn Panem der einzige Staat ist, macht eine zusätzliche Unterklasse von "Fiktionaler Ort" natürlich keinen Sinn. Aber mit der Ergänzung von p131 -> Panem sieht District 12 (Q14136664) doch schon ganz ordentlich modelliert aus. Was fehlt dir denn noch?  — Felix Reimann (talk) 10:13, 23 July 2013 (UTC)
English abstract: For me, country (P17) should be used in the strict sense of "a state as recognized by the UN" or similar to be helpful. No historic, no fictional things. Otherwise, the property has no advantage compared to model the same with a combination of located in the administrative territorial entity (P131) and instance of (P31): State. Thus, only items with all typical properties of states as in en:Template:Infobox country should be target of country (P17). However, I recommend using located in the administrative territorial entity (P131) also for fictional items and not create a second set of items only because they are fictional.  — Felix Reimann (talk) 10:13, 23 July 2013 (UTC)
Ah, I think I see the point and have misunderstood you before. It isn't the fact that you've got a problem with fictional items in special-properties, it is the fact that you'll just accept states recognized by the UN, right? Okay, but then the property name is bad chosen and the description is bad as well. I even begin to think about why a property for country should exist at all, as (as you said yourself) it can be solved over "is in the administrative unit". So how we will proceed now? Should I move "District 12" to "is in administrative unit: Panem" or should we change the usage of "country"? --Nightwish62 (talk) 19:11, 23 July 2013 (UTC)
What you are describing is an instanciation : a set of properties are associated with a class. The instances of that class are supposed to have statements built with these properties. So what you describe is perfectly compatible with usage of located in the administrative territorial entity (P131), and is even usualluy an important feature of its usage. Actually it's exactly the question I asked to EMW upper on this page and which i'll later develop and clarify because people have asked for, but later (it deserves a little time to write, as it's important, and I do not have enough time right now. (another point, UN can be used as sources in located in the administrative territorial entity (P131) statement to express that they are official states to discriminate with other kind of states. TomT0m (talk) 10:25, 23 July 2013 (UTC)
This sounds complicated to me, but it sounds interesting too! Is there any information in German I can read about it? --Nightwish62 (talk) 19:11, 23 July 2013 (UTC)
I have nothing in german, (i'm sorry I forgot everything from my school years), but I started Wikidata:Requests for comment/Typing : class ⇄ instance relationship in Wikidata a RfC to clarify and discuss that with everybody.
Remember that there are historic states which were members of the UN - East Germany, Czechoslovakia, USSR, Yugoslavia so a "member of UN" property won't tell you if the state is still a state unless you also check if it has an 'end date' qualifier. Filceolaire (talk) 12:23, 23 July 2013 (UTC)
All true. The point we discuss is: Where should the constraints be changed to allow fictional states like Panem or Gondor:
  1. country (P17) (I think: no, keep it in the strict sense according to whatever (tbd, not here)),
  2. located in the administrative territorial entity (P131) (I think: yes, target may be fictional, distinguishable per "instance of (P31) fiction or similar"), or
  3. none, keep it as it is. (as proposed below, create a whole new set of properties for fictional things)
Please choose!  — Felix Reimann (talk) 15:28, 23 July 2013 (UTC)
First to decide the usage and handling of country, than the constraints about it :). So see my text above. --Nightwish62 (talk) 19:14, 23 July 2013 (UTC)
2. Mixing fictional-world and real-world items, we will never build an ontology. Littledogboy (talk) 18:23, 22 July 2013 (UTC)
  Comment Fictional worlds have another rules. Constraints valid for real worlds can be invalid for fictional worlds at all. Maybe we need some way to identify fictional items and exclude its from all constraint checks. Related discussion: Wikidata:Property proposal/Generic#Is fictional. Bad side: every system that will use wikidata as datasource need checks "is fictional?" in every algorithm. — Ivan A. Krestinin (talk) 17:01, 22 July 2013 (UTC)
Why not?  — Felix Reimann (talk) 10:13, 23 July 2013 (UTC)

Islands in ocean / sea / lake

Is there a property I can use to say in which ocean or lake or sea an island is located? I was thinking of P131, in German called "liegt in", but the English label is ""is in the administrative unit", which doesn't sound like it could apply to a sea. Opinions? --Denny (talk) 21:26, 22 July 2013 (UTC)

Can't the geodata be used to determine this kind of feature ? An automatic way is better than a manual addition and as we already enter the geodata we have the raw material. We just need a code to calculate this. Snipre (talk) 22:03, 22 July 2013 (UTC)
As we don't have geoshapes, this does not work. --Denny (talk) 22:47, 22 July 2013 (UTC)
Yet we use shares border with... --Izno (talk) 22:12, 22 July 2013 (UTC)
P47 is also supposed to be used for administrative units, to connect them with administrative units of the same level. --Denny (talk) 22:47, 22 July 2013 (UTC)
Not yet, but you can vote for it here --Nightwish62 (talk) 22:45, 22 July 2013 (UTC)
Yay! Thanks, that looks right! --Denny (talk) 22:48, 22 July 2013 (UTC)

The same question for saying "this city is on this island". Not always do islands and administrative units coincide. --Denny (talk) 22:47, 22 July 2013 (UTC)

Can we create this property now? Filceolaire (talk) 12:34, 23 July 2013 (UTC)

I created the property right now, located in/on physical feature (P706) --Nightwish62 (talk) 20:01, 23 July 2013 (UTC)

Thanks Nightwish! I am going to use it right away :) --Denny (talk) 20:05, 23 July 2013 (UTC)

Legal/licensing issues

Issues regarding licensing, database copyrights and how they apply when bots try to import data from third-party databases have been discussed periodically in various forums (most notably bot approval requests such as Wikidata:Requests for permissions/Bot/MagulBot 3 and Wikidata:Requests for permissions/Bot/SamoaBot 32 but also on the project chat). These discussions typically involve a few people offering contradictory opinions on the topic and that's that. Since this is a recurring and pretty crucial issue and since there's so much confusion about it, I think it's time that we ask precise questions to the Wikimedia Foundation's legal team so that we can get definitive answers from professional and resolve these issues once and for all. Thoughts? Pichpich (talk) 04:55, 20 July 2013 (UTC)

I'm bumping this thread to note that I formally asked the WMF legal team to look into the issue. Luis Villa says that he has started looking at the issue and will provide some answers at some point in the future. Pichpich (talk) 19:54, 23 July 2013 (UTC)
Great idea, thanks!  — Felix Reimann (talk) 20:08, 23 July 2013 (UTC)

Edit section (of sites with language extension?)

When I'm trying to edit a section on this site I'm getting a error "You tried to edit a section that does not exist. It may have been moved or deleted while you were viewing the page.". Some questions about that:

  1. I'm I right this is because this site has the language extension?
  2. Is there any ongoing work, that selecting a section would be possible in the future?
  3. Is there any option to remove all "edit" links on the sections, just let the 'edit' on the top in the navigation bar?
  4. Could someone please change the error text and add a part which describes the right reason? Getting this error message is very confusing, as the most editors would think that the site surely exist. I think the text should be changed.

--Nightwish62 (talk) 20:20, 23 July 2013 (UTC)

Wikivoyage is here and new features/bugfixes

Heya folks :)

I'm super excited to welcome the first fellow sisterproject to Wikidata. We've enabled language links for Wikivoyage now \o/ Please give the travelers a warm welcome to our coozy hangout here.

In addition we've deployed some new stuff and bugfixes. The ones that are probably most interesting for you:

  • various bugfixes in API and geocoordinates datatpype
  • calendar names can now be translated (bugzilla:49080)
  • starting Thursday page moves on Wikipedia will change the sitelink in the respective item (This already works for Wikivoyage now but needs an additional update on Wikipedia on Thursday. bugzilla:36739)
  • and most importantly: improvements to the search ranking \o/ (This will not immediately have an effect but will improve over the next days and weeks. The weighting is very simple for now based on number of sitelinks an item has. An edit of either label, description or alias is needed to calculate the new weight for an item and for this to have an effect. We're interested in feedback in 2 weeks or so if this is good enough by then or if further improvements to the ranking need to be done.)

As usual please let me know about any issues you encounter. --Lydia Pintscher (WMDE) (talk) 21:58, 23 July 2013 (UTC)

Good news! :-) It works and works also the slurpInterwiki gadget! --Paperoastro (talk) 22:29, 23 July 2013 (UTC)
Well done everyone in getting it working so well :) Del♉sion23 (talk) 22:47, 23 July 2013 (UTC)
I'll just report that Merge.js also works. --Izno (talk) 22:52, 23 July 2013 (UTC)
On a side note, mass import started with item Q14201079, so items higher than 14.2 million will be likely to be duplicates of some sort. --Izno (talk) 00:35, 24 July 2013 (UTC)
Can't the import be done in some sort of smart way that minimizes the duplicates and stretches out the process over a longer period? It's not like we're in a race and in terms of managing editor resources, these duplicates are really bad news. The dups also make search results confusing. Pichpich (talk) 06:05, 24 July 2013 (UTC)
Actually, I am not sure most of those are duplicates. More likely, they are regional divisions which are different from Wikipedia (like Q14204511)--Ymblanter (talk) 06:35, 24 July 2013 (UTC)
Where we really have a problem is a situation where a WV article XX in language Y has no other Wikivoyage counterparts but has Wikipedia articles but not in Y (see voy:ru:Зао Онсен). But I assume these cases are relatively rare.--Ymblanter (talk) 06:41, 24 July 2013 (UTC)
Actually there seems to be quite many duplicates, even some where the Wikivoyage and the Wikipedia article have exactly same title. On the flip side, creating and merging may be the quickest way to sort this out.
By the way does a description like "regional division for Wikivoyage" really make sense. I do not think that the item scope needs to be restricted to Wikivoyage, even if there are currently only Wikivoyage links. --Zolo (talk) 06:52, 24 July 2013 (UTC)
I am completely open; if we can make here a more appropriate description it can be bot-added to all items which have the template {{Outlineregion}} or its counterparts in other languages.--Ymblanter (talk) 06:57, 24 July 2013 (UTC)
I would say that "the interior part of Iceland" is a good enough description, though a potential issue may be that Wikivoyage topics are not very clearly defined at the moment. --Zolo (talk) 07:06, 24 July 2013 (UTC)
I'd like to report this. --Superchilum(talk to me!) 10:03, 24 July 2013 (UTC)
I am afraid with this one we need to wait until the bot operators wake up. Some of the issues have been already reported at the bot's talk page.--Ymblanter (talk) 10:09, 24 July 2013 (UTC)

main page for oc missing

If I use Occitan and click on the Wikidata logo (Acuèlh = red link) I'm lost. --Martssnail (talk) 14:09, 24 July 2013 (UTC)

Fixed. Now it should go to Wikidata:Acuèlh which does not exist. I hope you can start the main page for Occitan language. --Stryn (talk) 14:21, 24 July 2013 (UTC)

Wikisource data scheme

I suggested data scheme for Wikisource which could eliminate problem of multiple interwikis implementation on server side. Sure, comments are welcome :-) --EugeneZelenko (talk) 14:19, 24 July 2013 (UTC)

Using translate extension for the Main Page

Hello, I propose to use the translate extension also on the main page. This has several advantages, using the translate extension all language versions stay up to date. For example has the English language version a much longer list of ways to contribute than the German and the Spanish version. These different versions of the same page can be really confusing. I see no need for different content in different languages. When also graphics to the main page should be added it gets more difficult to distribute them and the descriptions to all language versions. I propose to translate the page in user namespace first and then move it to Wikidata:Main Page. --Pyfisch (talk) 14:37, 23 July 2013 (UTC)

I like the idea that it would be easier for minor languages to keep up when things change. But maybe it would be better to make a setup where all sections can be made by transcluding a translatable page, like it is now for the news. That way you can setup a main page where everything is using the translate extension for some languages, while other languages still can decide to do some things differently. Byrial (talk) 22:40, 23 July 2013 (UTC)
I have not yet seen a useful difference between languages and also all other pages use the tranlation extension. --Pyfisch (talk) 19:26, 24 July 2013 (UTC)

"Wikipedia disambiguation page" and "Wikipedia category"

Has there been any discussion of what we should call these now that we're branching out to other projects? — PinkAmpers&(Je vous invite à me parler) 23:54, 23 July 2013 (UTC)

"wiki category page" and "wiki disambiguation page" would seem natural. --Izno (talk) 00:18, 24 July 2013 (UTC)
We should continue to call them instance of (P31) Wikimedia disambiguation page (Q4167410) and instance of (P31) Wikimedia category (Q4167836). If we get other types of Category or Disambiguation page then we can link those to an item appropriate to those pages. Filceolaire (talk) 00:28, 24 July 2013 (UTC)
I was talking about descriptions. But no, I disagree with you about categories. If there's a Category:United States on en.wy, then that should be linked to Category:United States on en.wp. We should just rename the items used for P31. Fortunately, in that regard, changing transcluded labels is much simpler than changing widely-used descriptions. — PinkAmpers&(Je vous invite à me parler) 00:32, 24 July 2013 (UTC)
Great thought. If such "items" were a different entity, we could make them descriptionless! Littledogboy (talk) 10:09, 24 July 2013 (UTC)
I like that. Someone wanna write a bot to change the hundreds of thousands of effected items? — PinkAmpers&(Je vous invite à me parler) 00:32, 24 July 2013 (UTC)
Could that bot add instance of (P31) property to each of these pages at the same time? Filceolaire (talk) 10:52, 24 "July 2013 (UTC)
And remove any GND claims? :) --Izno (talk) 21:55, 24 July 2013 (UTC)
We have similar issues with items like Q16503. --Rschen7754 07:06, 24 July 2013 (UTC)

Please see also Talk:Q5296#wikivoyage. --Stryn (talk) 09:57, 24 July 2013 (UTC)

Will comment there. --Izno (talk) 21:55, 24 July 2013 (UTC)

By the way, since we use "wiki category page" for instance of, what do we set for the GND main type property? since the disambiguation page are set to a special value for main type. --Napoleon.tan (talk) 14:55, 24 July 2013 (UTC)

I don't think any of the GND Main Types are appropriate for these pages and so I would be against having any GND Main types for these (in accordance with the recent RFC). Filceolaire (talk) 15:40, 24 July 2013 (UTC)
Don't use GND type. Please and thank you. Use instance of. --Izno (talk) 21:55, 24 July 2013 (UTC)

Caption

How do I add an caption? Example infobox oc:Jane Fonda: "Jane Fonda al Festenal de Canas de 2007." --Martssnail (talk) 14:13, 24 July 2013 (UTC)

This is the caption of the corresponding image. As Commons is not yet integrated in Wikidata, this is not possible. You find the currently available properties at Wikidata:List of properties.  — Felix Reimann (talk) 18:32, 24 July 2013 (UTC)
Good to know. I've submitted a proposal for "caption". The property could be used as a qualifier. I hope the data type (multilingual) is correct. --Martssnail (talk) 19:43, 24 July 2013 (UTC)

Brands

Quick question about instances versus classes. Take as an example Solo (Q504281). This is a brand (brand (Q431289)) of soft drink (soft drink (Q147538)) but how should that basic statement be represented? Neither subclass of (P279) nor instance of (P31) seem appropriate. Do we want a separate property to express this? Pichpich (talk) 21:42, 19 July 2013 (UTC)

If we consider Solo (Q504281) to be a kind of soda (which the English Wikipedia article Solo calls the subject), then it's clearly a class: the item would be describing properties of all individual bottles of Solo, and not any particular instance of Solo (e.g. a specific bottle that you yourself would be drinking).
The Wikipedia article Brand leaves the definition of "brand" a bit vague: "Brand is the 'name, term, design, symbol, or any other feature that identifies one seller's product distinct from those of other sellers'". But if consider the traditional meaning of brand -- a distinctive kind of symbol a rancher would burn into their cattle's skin -- then I think a brand would be a class of thing, and instances would be the actual physical burn on a particular animal's skin. Emw (talk) 00:15, 20 July 2013 (UTC)
How about Hamlet (Q41567) with this approach, if I may ask? Instance or class? Littledogboy (talk) 00:23, 20 July 2013 (UTC)
Class, so subclass of (P279). I have an instance of (P31) of Hamlet (Q41567) on my bookshelf! Q41567 describes all such instances. Emw (talk) 00:37, 20 July 2013 (UTC)
Now tell me, on 26 July 1602, the minute Shakespeare finished writing it – was it already a class of items? Littledogboy (talk) 14:38, 20 July 2013 (UTC)
If by "it" you mean the item represented by Hamlet (Q41567), then yes: it would have been the only instance of that class of thing. Emw (talk) 14:56, 20 July 2013 (UTC)
I have got a question about that. If Hamlet is not an instance of anything by itself, how do you take granted that, unless other subclasses of creative work, Hamlet have a unique identifiable author? The instance of a class relationship, in semantic web, implies a set of properties associated with its instances. Not the subclass relationship who can imply a bigger set of properties associated to those instances. TomT0m (talk) 16:16, 20 July 2013 (UTC)
TomT0m, I can't wrap my head around this paragraph. Littledogboy (talk) 01:14, 22 July 2013 (UTC)
Me neither. TomT0m could you rephrase your comment so it is about the Wikipedia Hamlet page rather than so theoretical individual book.
For me Hamlet in Wikipedia can be either of two things. An instance of a Play or an instance of a Fictional Character depending on whether the wikipedia page is about the play or the character. Filceolaire (talk) 01:18, 23 July 2013 (UTC)
OK, now what about Mona Lisa (Q12418)? Littledogboy (talk) 13:50, 21 July 2013 (UTC)
Although there are many copies of the Mona Lisa, the English Wikipedia article on Mona Lisa discusses the subject's theft and vandalism, and conservation. It discusses the item as a token, not a type, of thing -- i.e. something that has a unique location in space and time. So I think Mona Lisa (Q12418) is best classified as an instance. Emw (talk) 14:09, 21 July 2013 (UTC)
There may be many copies but there is only one original and I agree that is an Instance of a painting. Filceolaire (talk) 01:40, 23 July 2013 (UTC)
Thanks for your patience. United States public debt (Q1138777)? Littledogboy (talk) 15:55, 21 July 2013 (UTC)
Interesting question. United States public debt (Q1138777) is a sum of money which the USA owes so I think it is an instance of something. Probably an instance of an economic statistic. It is not a collection of similar things so it is not a class nor a subclass. Filceolaire (talk) 01:40, 23 July 2013 (UTC)
And what about the $100 you owe to your grandma? That surely must be instance of debt (Q3196867)? This cannot be a class of things, can it? Littledogboy (talk) 10:48, 25 July 2013 (UTC)
You could choose instance of both of the two. It is not immediately apparent (or even likely) that soft drink is a subclass of a brand, nor that the opposite is true, and so it seems that Solo is both. Alternatively, we should attempt to pick one if possible. My tendency would be to call it instance of soft drink, as the fact that it is a brand is much less relevant in the grand scheme of things. Coca-Cola is the same (or was; I plan to change that to instance of cola, if I can find that). (On a side note, it might even be worth it to call them both a subclass, as the only case in which it is an instance is when I have the Coca-Cola can in front of me and I am drinking it.)
We might also infer the fact that it is a brand from the length of time it has been in production, though this is a very weak inference and not necessarily one shown by the data. --Izno (talk) 00:17, 20 July 2013 (UTC)
So Solo (Q504281) is
an instance of (P31) a brand (Q431289) since there are millions of bottles of Solo but there is only one Solo brand;
and is a subclass of (P279) soft drink (Q147538) since it describes thousands of bottles, all of which are soft drinks;
and is a part of (P361) Ringnes (Q1334431) - one of the companies that owns this brand.
or maybe not. Filceolaire (talk) 00:50, 20 July 2013 (UTC)
I'll say when we talk of a soda we talk of two things : a recipe, and all kinds of drinks that follow this recipe. The the recipe of this kind of soda is an instance of soft drink recipe. The soda bottle which countains drinks with this recipe is an instance of soda bottle of brand brand, which is a subclass of soda bottles. In the end this class of soda bottle is an instance of something like branded sodas (with plural), which is a class that make sense. I'm trying to be as much precise and complete as I can, but it's a lot of statements ;) . TomT0m (talk) 10:17, 20 July 2013 (UTC)
Sorry TomT0m. Still don't understand what you are getting at. Can you tell us what properties and values you thing Solo should have in practice rather than in theory? Filceolaire (talk) 01:18, 23 July 2013 (UTC)

In general

Wikivoyage phrasebook

Should they be listed along with their respective language. For example should Akeanon phrasebook be placed into Akeanon language. Del♉sion23 (talk) 22:50, 23 July 2013 (UTC)

I'm not sure about that. That aside, we might want to invite the WikiVoyage peoples to see if they would like that. --Izno (talk) 22:53, 23 July 2013 (UTC)
Personally, I'm leaning towards merging them, as one looks at the language from a travel perspective, and the other from an encyclopaedic perspective, just as in any other item with both Wikipedia and Wikivoyage links. But yes, it would be good to get Wikivoyager opinions on the idea. Del♉sion23 (talk) 23:08, 23 July 2013 (UTC)
I personally would list them at the language page, but I will not open a topic at the Wikivoyage Lounge to get a broader opinion.--Ymblanter (talk) 06:01, 24 July 2013 (UTC)
You said "will not". Did you mean that? Filceolaire (talk) 06:45, 25 July 2013 (UTC)
I am sorry, no, I did not mean that. I actually opened a section yesterday there, meta:Wikivoyage/Lounge#Wikidata and Phrasebooks.--Ymblanter (talk) 07:36, 25 July 2013 (UTC)

An error of edit summary?

I found a strange edit summary while looking around the history of Q20317. In this edit, an IP user added a link to jawiki. Nontheless, the edit summary for that edit is "Added link to [enwiki]: Liancourt Rocks". Is it an error of the software that gives edit summaries?--Bluemersen (+) 07:59, 24 July 2013 (UTC)

In theory the editor could've pressed "undo" and entered that summary just to fuck with us. But I doubt it. I'm going to sleep, but if someone wants to ping the devs or just file a bug, that'd be great. — PinkAmpers&(Je vous invite à me parler) 03:58, 25 July 2013 (UTC)
It's not possible to make this kind of summary when undoing edit. --Stryn (talk) 05:55, 25 July 2013 (UTC)
Tracked at bugzilla:51953 ·addshore· talk to me! 15:54, 25 July 2013 (UTC)

merge tool

Seem don't work in voyage item, dont put the deletion request and dont merge on the oldest itemRippitippi (talk) 11:10, 24 July 2013 (UTC)

If this is indeed the case, can we shut down the Wikivoyage bot imports for now? It's already a nuisance to have to deal with a sudden influx of duplicates but if we don't even have the tools to deal with them here, we should stick to manual additions of wikivoyage links for now. Pichpich (talk) 14:17, 24 July 2013 (UTC)
At this time almost all item imported are duplicates Rippitippi (talk) 14:49, 24 July 2013 (UTC)
I don't have any problems with the merge tool. But it's a big problem that bot makes so many duplicates. But it's because so many pages on Wikivoyage doesn't include link to Wikipedia. --Stryn (talk) 14:52, 24 July 2013 (UTC)
And bot create empty item like Q14238459 or Q14238789 Rippitippi (talk) 14:53, 24 July 2013 (UTC)
I blocked the bot, creating empty pages means it is malfunctioning. I might be unavailable for the rest of the day; everybody should feel free to unblock it once the problem has been solved.--Ymblanter (talk) 15:14, 24 July 2013 (UTC)
Good idea. Of its last 40 items created, 75% needed to be merged, 2 of which were completely empty items. Seeing as the bot has already got to "W" in its list, there must now be 1000s of items needing merges and/or deleting... Del♉sion23 (talk) 18:42, 24 July 2013 (UTC)
this is quite surprising: didn't the bot's user or other users notice that the bot was doing almost everything wrong? --Superchilum(talk to me!) 09:17, 25 July 2013 (UTC)

Interwiki links to Wikivoyage

Hi, what is the preferred way to make interwiki links to Wikivoyage pages in my database reports etc.?

Is it voy: first, and then language code:

Or language code first, and then voy:

Both ways works. Which one should I choose? Byrial (talk) 11:55, 25 July 2013 (UTC)

I would say the first. Because the latter redirects via Wikipedia. --Stryn (talk) 12:47, 25 July 2013 (UTC)
And the first redirects via the English Wikivoyage. Well I think you are right that this is better. It is the only one that will work for the unlikely case if there ever is created a Wikivoyage project for a language without a Wikipedia. Byrial (talk) 13:00, 25 July 2013 (UTC)

Distributed computing

Hi everyone. Have you ever thought about using the power of distributed computing with Wikimedia's projects? We could use it to help bots performing their tasks (not for every bot, but after a discussion of course). I think it could be very useful! --79.20.80.224 14:59, 25 July 2013 (UTC)

I don't understand you. Bots can already run on Wikimedia Labs (and Toolserver). Which ressources do you want use for distributed computing and who should use them? --Pyfisch (talk) 16:07, 25 July 2013 (UTC)
If you would have a look at [7]. This is a diagram of the server infrastructure of wikimedia as of 2010. This IS heavily distributed. You comment is like "Hey UPS, if you would buy more than one truck, you could deliver your parcels even faster!" :) And with Wikimedia Labs, distributed computing is also already available for bots.  — Felix Reimann (talk) 16:10, 25 July 2013 (UTC)
Here are some pictures of one datacenter Wikimedia uses: commons:Category:Wikimedia_servers_in_2012  — Felix Reimann (talk) 16:16, 25 July 2013 (UTC)
I just thought that it can be useful. It seems not to be. --79.20.80.224 16:29, 25 July 2013 (UTC)

Make embedding data in wikipedia human readable

Please have a look at https://www.wikidata.org/wiki/Wikidata_talk:Infoboxes_task_force#Make_embedding_data_in_wikipedia_human_readable We need some discussion--Biggerj1 (talk) 15:14, 25 July 2013 (UTC)

Bug?

Is there any bug in the software? When I logged in today and clicked on my contributions, this is what I see:

(show/hide) 21:57, 21 July 2013 (diff | hist) . . (+254)‎ . . <wikibase-itemlink> ‎ (→‎wbsetclaim-create:1||1: <wikibase-itemlink>: <wikibase-itemlink>)

Anyone knows something about this? — ΛΧΣ21 16:21, 25 July 2013 (UTC)

Actually, the same happens when I edit an item. It's everywhere :( — ΛΧΣ21 16:24, 25 July 2013 (UTC)
Yeah this is broken atm. We're working on fixing it. --Lydia Pintscher (WMDE) (talk) 16:26, 25 July 2013 (UTC)
It is fixed now. The localisation cache for wikibase was obviously broken and took some time to rebuild it all. Aude (talk) 17:45, 25 July 2013 (UTC)
I see. Thanks! — ΛΧΣ21 18:25, 25 July 2013 (UTC)

Fictional character's GND main type? person or creative work?

I would like to clarify for a fictional character like a comic book character. Are they a person which could have sex? or are they a creative work which could have instance of value of character? I look around on some items and some use person and some use work but both have sex and instance of value to character. --Napoleon.tan (talk) 14:13, 25 July 2013 (UTC)

Just make sure you have instance of (P31) fictional character (Q95074). Then add all the properties you would for a person. Filceolaire (talk) 22:38, 25 July 2013 (UTC)

Merging for "Significant other" item

I suggest merging Q841509 and Q1374278, but I don't how to do it. --92.255.152.30

There appears to be a conflict between lover and significant other in the Chinese links. Del♉sion23 (talk) 21:32, 25 July 2013 (UTC)
Fixed --46.146.111.139 09:00, 26 July 2013 (UTC)
  Merged with gadget. Infovarius (talk) 16:43, 26 July 2013 (UTC)

Disambiguation questions

Can I ask interested people in here to join this discussion? --Superchilum(talk to me!) 07:23, 26 July 2013 (UTC)

Next office hour

Heya folks :)

Denny and I will be doing another office hour for all things Wikidata after Wikimania. Everyone is welcome to ask questions. We'll be doing this on IRC in #wikimedia-office and start with a quick update in the current state of Wikidata and its development. It'll be on the 26th of August at 16:00 UTC. For your timezone see here.

Hope to see many of you there. --Lydia Pintscher (WMDE) (talk) 16:52, 26 July 2013 (UTC)

What property should I use

Most country articles on Wikipedia will have subpages on particular aspects of that country. <China> for instance has pages on

  • Names of China
  • History of China
    • Chinese Prehistory
    • Dynasties in Chinese History
    • Republic of China (1912–1949)
    • History of the Republic of China
    • History of the People's Republic of China
  • Geography of China
    • Wildlife of China
  • Environment of China
    • Water resources of the People's Republic of China
  • Politics of the People's Republic of China
  • Administrative divisions of the Republic of China
etc.

What property should we use to link these subpages to the main page?

  1. Is history of China (Q82972) a part of (P361) or a subclass of (P279) People's Republic of China (Q148)?
  2. Should we rename category's main topic (P301) so it can be used for this case?
  3. Should we add country (P17) People's Republic of China (Q148) to each of these pages? If yes then what do we do when the main page isn't a country?
  4. Should we create a new property?

Filceolaire (talk) 00:14, 24 July 2013 (UTC)

My opinion: No, no, no, and probably not. --Yair rand (talk) 08:40, 24 July 2013 (UTC)
You could propose an item-property "history of" for such cases. I certainly think that that would be useful. --Tobias1984 (talk) 09:05, 24 July 2013 (UTC)
Could we not generalize that ? something like an is about <China> qualified by detailed aspect <History>. Then we could use the same property and qualifier for China's economy for example. TomT0m (talk) 15:51, 24 July 2013 (UTC)
That is a great idea! That way it could be applied to a lot of items where certain details are dealt with in separate Wiki articles. Are you going to propose it TomT0m? --Tobias1984 (talk) 19:20, 24 July 2013 (UTC)
I would tend to disagree that this in general is a good idea. At that point, we're classifying the article (I would claim) and not its real world implications (whether from the "is about" perspective or the "history of" perspective). --Izno (talk) 20:59, 24 July 2013 (UTC)
You're right, is about is a very wrong label. Actually thinking about it, it seems redundant with something like instance of <country economy> which could be qualified with the concerned country. I can't wrap my head to know it's my idea who is wrong or just the label :). TomT0m (talk) 07:59, 25 July 2013 (UTC)
  1. I would say that is does have the relation "part of", being both part of China and part of history. I could be argued away from this thought.
  2. No.
  3. No.
  4. See answer to Tobias et al.
--Izno (talk) 20:59, 24 July 2013 (UTC)
IMHO, is about or main topic + qualifier would be best - LaddΩ chat ;) 22:39, 24 July 2013 (UTC

We should also have some vague properties, to express for example that supply and demand (Q166656) is term/concept from economics (Q8134). Do you agree? Littledogboy (talk) 10:43, 25 July 2013 (UTC)

I think 'is part of' works for that case. Filceolaire (talk) 22:19, 25 July 2013 (UTC)
I would agree with Fil on that opinion. --Izno (talk) 22:20, 25 July 2013 (UTC)
Part of seems to be a lot stricter to me, and this would definitely be against how it is conceived in Help:Basic membership properties... And I like this help page, I think it is a good starting point for our endless discussions. Littledogboy (talk) 13:45, 26 July 2013 (UTC)
The key is in this "whole-part" relationship. No matter how many economic terms you put together, you will never get economics – in contrast with the manner in which the sum of your organs makes up your whole body, or chapters make up a novel. Littledogboy (talk) 23:04, 26 July 2013 (UTC)
Emw always has an interesting opinion (though I believe and agree with what you're saying). Maybe ping him?
The problem to me arises (either way, I guess, since part of obviously does not illustrate class/subclass) in that we end up with supply and demand subclass of term/concept, and that's definitely not a useful thing to say (per all the reasons term sucks for the GND types). --Izno (talk) 23:12, 26 July 2013 (UTC)

Interwiki links

The english Furo article links to its japanese equivalent 風呂 article. However, when I try to link the english Bathroom article to the japanese equivalent 浴室 article, I can not do so. Because 浴室 redirects to 風呂. Certainly, this can not be the correct behavior, right? Lordmetroid (talk) 09:53, 26 July 2013 (UTC)

I suppose that en:Bathroom is an article about general term (not about english bathrooms) and en:Furo is about japanese ones. Which ja-name is more general (independent of country): 風呂 or 浴室? And are you going to describe japanese bathrooms and any bathrooms in different articles? --Infovarius (talk) 16:37, 26 July 2013 (UTC)
en:Bathroom is an article about the general term while en:Furo is an article about japanese bathtubs. 風呂 is the Japanese for bathtub, so en:Furo is correctly linked to the ja:風呂 article. But because there is no article in Japanese about the general term bathroom, the ja:浴室 article redirects to ja:風呂. Which results in that en:Bathroom can not have a link to the ja:浴室. I wasn't about to write an article at all. I just wanted to link the articles correctly. Lordmetroid (talk) 23:35, 26 July 2013 (UTC)
  Done I've added the Japanese link to en:Bathroom using the old lang link method. Wikidata does not link to redirects, so we have to go back to the old way of adding them. Hope this has fixed the problem. Del♉sion23 (talk) 23:58, 26 July 2013 (UTC)
There is currently 42 Wikipedia links in bathroom (Q190771), so you should ideelly add that interwiki link in all 42 Wikipedias instead of just one. Another way to fix it for all of these would be to edit ja:浴室 to make it an ordinary page, add the page to bathroom (Q190771), and then immediately make it a redirect again. Byrial (talk) 04:10, 27 July 2013 (UTC)

Maps gadget

Hi guys, Wikidata has got lots of coordinates as statements. I've created a tool called "maps.js" which allows you two watch this coordinates on several interactive maps, OpenStreetMap and the WikiMiniAtlas. Try it out by writing 

importScript( 'User:Bene*/maps.js' ); // [[User:Bene*/maps.js]]

into your common.js. If you like the script it could also become a gadget. Please also report bugs on the script's talk page. Regards, -- Bene* talk 20:02, 15 July 2013 (UTC)

Great, thanks! Ayack (talk) 08:34, 16 July 2013 (UTC)
Indeed great! :) ·addshore· talk to me! 10:24, 19 July 2013 (UTC)
Awesome! Thanks a lot! --Quico (talk) 11:44, 22 July 2013 (UTC)
Thank you, Sir. Nice work !  Ę-oиė  >>>  ™ 08:49, 23 July 2013 (UTC)
Where can I find information about how to use common.js. I tried creating a common.js page, and pasted the code. I think I did it correctly, but what is supposed to happen? -abbedabbtalk 09:41, 27 July 2013 (UTC)

Wiki Loves Monuments

I think it would be a good idea to import in Wikidata the Wiki Loves Monuments database. It contains many structured data regarding various objects of cultural heritage value which could be easily imported via a bot. What do you think about it? Ayack (talk) 20:18, 24 July 2013 (UTC)

Sounds like a good idea. Filceolaire (talk) 17:54, 25 July 2013 (UTC)
We had a page about it which I can not find at the moment. It was created by Multichill.--Ymblanter (talk) 18:19, 25 July 2013 (UTC)
It's Wikidata:Cultural heritage task force. odder (talk) 16:06, 27 July 2013 (UTC)

So curious about the search

Please see this search. I am so curious to know how we are getting the right result from Malayalam wikipedia --Vssun (talk) 17:42, 27 July 2013 (UTC)

Does wikidata search uses the index from Wikipedias also? --Vssun (talk) 17:45, 27 July 2013 (UTC)

Ok I got it. The item had an alias (the same search term) --Vssun (talk) 17:48, 27 July 2013 (UTC)

How do we identify animal genders?

Hi, some closed discussions on property sex or gender (P21) made it clear that only persons can be male or female; qualifiers like male organism (Q44148) and female organism (Q43445) seem unused... How can I enter the gender of dog Blondi (Q155695) or polar bear Knut (Q159697) ? -- LaddΩ chat ;) 23:33, 25 July 2013 (UTC)

This seems to be a gender vs sex issue. Animals can have a defined sex (i.e. which organ set they were born with), but it doesn't make sense to define animal gender since the two can't be different (maybe they can, probably a debate for another place). Ajraddatz (Talk) 04:38, 26 July 2013 (UTC)
Well, wasn't one of the big problems, that many languages separate the words for humans and animals? I know that the Swedish Village Pump was filled with complaints that people were classified as beasts on Wikidata. -- Lavallen (block) 05:32, 26 July 2013 (UTC)
In that case we need another property for animal-gender. I still think it would be practical if a group of properties could also be a subclass of another property. That way human-gender, animal-gender, genetic-gender etc... could all be a subclass of the property "gender", thereby also making more general or more specific queries possible. --Tobias1984 (talk) 06:39, 26 July 2013 (UTC)
Both human-sex and animal-sex refer to the same entity: the classification of the sexes. The distinction between them is caused by a language problem. Such distinction also brings another problem into discussion, which is representing the same entity with two set of items (human male+female+transgender, etc and animal male+female, etc). Technically there should be only one item to represent one entity, which is not the case here. If Wikidatians don't mind, I recommend tolerating the language issues, and classify both animals and humans under one sex property. --Wylve (talk) 18:10, 26 July 2013 (UTC)
You did see the comment from Lavallen above? Using Male and Female for animals is a problem for other languages - not English. It is therefore not appropriate to suggest ignoring this problem on the English Project Chat. Filceolaire (talk) 21:16, 26 July 2013 (UTC)
Actually beeing a man or a woman is the intersection of beeing a human and your sex. It seem to be a display and vocabulary problem, not a semantic one. Then different Wikipedia can choose to display information like they want with their cultural differences as soon as there is enough information in the database, and presently there is no doubt it is the case, there is enough information to deduce what should be displayed. But Wikidata should matter of semantics, which is as much as possible language independant. TomT0m (talk) 21:29, 26 July 2013 (UTC)
One more thing : in manchester syntax it is totally possible to define (formally and syntactically) a 'Woman' and a 'men' with a constraint Types : hasSex value "male" or hasFirstName value "Jack"^^xsd:string and a SubClassOf: Homo sapiens clause. But it's not yet in my proposal ;) TomT0m (talk) 21:42, 26 July 2013 (UTC)
So if we agree that it is the right property but that it's preferable to have different qualifiers, I see no reason to exclude male organism (Q44148) and female organism (Q43445) from sex or gender (P21). I'll push this to the Property talk:P21 -- LaddΩ chat ;) 00:14, 28 July 2013 (UTC)

es:Marcas corporativas de Wikipedia

Are the interwikis correct? They don't seem to be correct to me, but I don't know about Wikidata's rules about the Project namespace, etc. πr2 (t • c) 21:39, 27 July 2013 (UTC)

Wrong in principle, but I don't see any advantages to separate those pages, just because somewhere it's on Wikipedia namespace, and somewhere not. This is same kind of "problem" than e.g. Slovene Wikipedia (Q14380) which is in Wikipedia namespace in fi-wiki, but in article namespace on other Wikipedias. But it does not make sense to separate fi-wiki link just because it's on different namespace. --Stryn (talk) 21:46, 27 July 2013 (UTC)

How long should property proposal discussed?

I proposed to create some properties in May, now is July, but properties did not create yet. I need them in articles. I am saying about UIC station code, Department or region of railway, Station type and similar.--Ahonc (talk) 11:09, 28 July 2013 (UTC)

Can you post the links to the proposals? --Tobias1984 (talk) 11:49, 28 July 2013 (UTC)
Added.--Ahonc (talk) 12:16, 28 July 2013 (UTC)
We obviously got a problem with property management. It's slow, some of them stays uncommented, it lacks some sort of consistency (we should be able to discuss a whole set of properties). TomT0m (talk) 11:55, 28 July 2013 (UTC)
I think the two main points are that the reviewers are missing and that the pages are a huge mess. We need more people voting and more people tidying. In the most recent archive most of the creations were done by Nightwish62 and me. Maybe somebody is interested in sharing the workload. --Tobias1984 (talk) 12:13, 28 July 2013 (UTC)
Of course but imho if we have a people problem it's because we have a protocol problem. We should think of stuffs such that those pages are less of a mess, maybe having less proposals ... for example the classification of properties should be better and more fine grained and more alignde with the structure of task forces for example. I also think that if we took proposals as a coherent thing to express something and proposed amends to a whole domain specific model instead of just thinking and voting property by property this could be better. In my view, ans it's one of the things I'm trying to do with Help:Modeling and my proposal for a language, one alternative could be Now we have this model, for example for bibliography stuff, I propose to change it to this one (just adding one or two properties most of the time), we vote as a whole in some subpage of the task force page with an announce on property proposal pages, and created the property if that's approved. That way it's easyer to clean, we keep things more organized, coherent and information easier to find, and closer to people which are really interested. Maybe things would get smoother (but I'm writing nearly random thoughts so those might not be all to take). TomT0m (talk) 12:26, 28 July 2013 (UTC)
You are right about the organization of the pages. Do we sort them by main type? Why not sort them into science departments (biology, chemistry, ...). Finding things on some of the pages is also a big mess, but for that we need more people voting 'oppose', so we can send bad proposals to the archive. --Tobias1984 (talk) 15:32, 28 July 2013 (UTC)
Saying we need more people voting won't make them come, they were here and went away because the process is tedious. We need to change the process to make them coming back stably. Not voting means "I don't care", not "the proposal is bad". This is why we should put those proposals to people who actually cares about the subject and leave those who are not interested with things they care about. It's also why we can gain into presenting things in their context : a proposal which do not make obvious sense by itself at first sight, and will not recieve any vote, can make a lot more sense presented in its context, where it's meant to be used. TomT0m (talk) 15:48, 28 July 2013 (UTC)
I agree with everything you say. A possible solution I can think of is to nominate more property creators. We could add to the job description that they have to keep the proposal pages organized and sorted. --Tobias1984 (talk) 16:03, 28 July 2013 (UTC)
I think (just thinking) we should be lazier and ask the minimum to creators: having proposals organized by project or by model, or by types (or both), such as having one page by type, and having some sort of type modification proposal, with an announce both on project chat and on property proposal page. As such proposals are already organized naturally by project, no other maintenance task added for projects creator. In short a model closer to page deletion proposals in french Wikipedia where discussions take place into a subpage of the discussion page of the article proposed to deletion, and people interested get the announce on the project chat, or discuss directly there. The type or model (or infobox) approach would make it possible to easily view what already exists for properties for the concerned type of items. Then the vote would become modify the model (or infobox) according to this proposition, so maybe just one vote for several properties. Then the property creator job become to check the announce and to see if this discussion is finished or not. TomT0m (talk) 16:15, 28 July 2013 (UTC)
Other solution : we are not that many interested into those discussion, so the rule should be : if nobody cares, the proposer is right. So people have to move only when they are really opposed. TomT0m (talk) 17:37, 28 July 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ Well the bar is already set pretty low. Proposals sometimes go through with only two supporters. But I don't think that that is a problem. A lot of properties are just basic infobox information that needs to be stored anyway. Creating properties without support is a little risky in my opinion because a lot of times the datatype is wrong. --Tobias1984 (talk) 18:12, 28 July 2013 (UTC)

  • This is real problem. Some my properties wait for supporters 4 months. I think PP is very bureaucratic procedure. This is exception from standard wiki techniques. We have no "Article proposal" in Wikipedia, we have no "Item proposal" in Wikidata, why we need "Property proposal"? If users select bad datatype this says that our documentation is bad. I think we need remove PP at all, improve documentation and resolve problems on Property deletion if needed. — Ivan A. Krestinin (talk) 20:00, 28 July 2013 (UTC)
We already discussed it in this RfC as you know because you has also participated in the voting. There was a broad agreement about restricting the creation of properties. And there are no reason why the situation should have changed in the meanwhile. Obviously you don't see any problems in creating properties, using them broadly and then deleting them again, but I do and I think other too. The compare to Wikipedia doesn't work, as you can't compare properties with Wikipedia articles. If you like, you can compare items with articles, but not properties. And items are allowed to be created for everyone. However, this section is about how to handle property proposal, not about if we should remove the restriction or not. If you like to challenge the restriction, please start a new section for it. --Nightwish62 (talk) 20:38, 28 July 2013 (UTC)

Yes, we really have a problem with property proposal. Just some thoughts about it:

  • I already indicate to that situation some weeks ago in this discussion here. The point is: TomTom is right, even such discussion doesn't get much interesting. I don't know what the most other users here are working on and I'm really surprised, because the properties are one of the most important key elements anyway in this project.
  • As I already mentioned there (see link above), I think people are tired of unsatisfactory situation like we should use generalized or specialisiered properties or not. Many property proposals ends in an RFC and even those remains without decision for month.
  • I don't think more property creators in general would solve the problem. The most property creators we have at moment, just have the permissions because they was interested to create one of their own properties in the past. After that, they aren't really interested to handle the proposals of other people. So we need some property creators which are really interested to help us handling the proposals.
  • Instead of trying to better organization the pages, we should execute as many as possible to make the list really short. Nobody wants to scroll through endless lists. So we should get rid of the legacy of the past. I'm sure there are more attention to the property proposals when the list is short.
  • I agree in some parts to the statement "if nobody cares, the proposer is right". Everybody has the possibility to voting oppose a property proposal, so when nobody is raising his voice the property seems right even if there are no supporting votes at all. However, I don't feel really good when creating such properties, because I don't like see them requested for deletion after they was created and already used in statements. It's like: First nobody participating in the proposal discussion, but afterwards some users are crying about unnecessary properties. This is frustrating for everyone. So it would be good if there are enough votes (whatever support or oppose), but we can't wait month for it.
--Nightwish62 (talk) 20:24, 28 July 2013 (UTC)
I think you are raising an interesting point: "The most property creators we have at moment, just have the permissions because they was interested to create one of their own properties in the past."
What about this new system for giving property creation rights?
  • After X number changes in Wikidata everyone gets property creation rights
  • The person proposing the property can create the property if afer a week there was no opposition nor concerns
  • If after a month there is no consensus reached, the proposal is dismissed.
I think it would speed things up, it will give the responsability of creating the property to the person that wants to have it (the proposer), and it would clean up the list. --Micru (talk) 22:25, 28 July 2013 (UTC)
At this point I actually don't think that creation rights are a problem anymore. I found this proposal and 3 of the 4 people in the discussion have property creator rights. So either nobody needs the property anymore, because a different solution was found, or none of property creators wan't to create it. Right above that proposal is this proposal which is absolutely unrealistic by our current standards. Nobody is bothering to vote 'oppose' (since April), so it is just going to sit there for months. Just like adminship is defined by a certain amount of activity we should make it a rule that property creators have to make a certain amount of edits to the proposal pages (especially opposing bad properties and sending them to the archive). --Tobias1984 (talk) 07:35, 29 July 2013 (UTC)
Sorry, but I think property creators are not the problem: most of the current properties proposals are not followed by the persons who proposed them so even if some contributors put some comment or are opposed to the current proposal nobody tries to develop the proposal in order to reach a larger approval. Then a lot of proposals imply the definition of a general structure for data: if we structure the data for biology/country/persons in a certain way, it is better to do the same for other fields and to avoid specific rules for each class of items. Just remind that later you will have to extract the data from wikidata DB in Wikipedia and in order to reduce the need of code a unique strucutre of data will help a lot.
For me the problem is as explained by TomTom in the formulation of the proposals: contributors have some ideas, just come to create their propopal without a clear idea of how the data are already strutured in Wikidata and don't follow the discussions about the proposal. After that it is difficult for property creator to do anything: if some open questions (comment or opposition) stay you can't create the property and you don't want to delete anything because you are not an expert in every subject and the property can be useful.
The best solution is to prepare the proposals first by listing all useful properties used to describe an item class, and to do that in a specific task force or in the infobox task box. Don't discuss the property there and list all properties there. Then once you have a good idea of the property, their datatype and their framework, you can propose them in batch way. Property proposals need to be prepared that's the key factor to see a proposal reach its creation. Snipre (talk) 09:35, 29 July 2013 (UTC)

Problem with WikiVoyage link bot

Sitelinks to WikiVoyage pages about Tokyo have been put on 'ward area of Tokyo (Q308891)' instead of 'Tokyo (Q1490)'. What is up with this bot? Filceolaire (talk) 13:07, 28 July 2013 (UTC)

Looking in more detail I see there is a different collection of wikivoyage pages linked to 'Tokyo (Q1490)'. The Wikivoyage sitelinks on 'ward area of Tokyo (Q308891)' should probably be on 'Tokyo (Q11199581)'
There are pages describing the prefecture of Tokyo, and others about the city of Tokyo. This is a way to have them separately.--Ymblanter (talk) 15:17, 28 July 2013 (UTC)

Question

For the description section of items on communities, is it better to mention what part of the county the community is in (like here) or just the county it is in (like here)? --Jakob (Scream about the things I've broken) 11:16, 28 July 2013 (UTC)

Use located in the administrative territorial entity (P131) to link to the smallest administrative division which contains the subject. You can use located in/on physical feature (P706) as well if you want.
contains the administrative territorial entity (P150) is only used to link to units which are smaller than the subject of the wikidata page and are enclosed within it. P150 is the inverse of P131. In general P131 is preferred (on the smaller unit, linking to the one larger unit which contains it) rather than P150 (on the larger unit, linking to the multiple smaller units it contains) so we go from smaller to larger and reduce the number of properties in a page. Filceolaire (talk) 11:57, 28 July 2013 (UTC)
We need to index and store those informations. TomT0m (talk) 12:12, 28 July 2013 (UTC)
I've started cleaning up the mess I created. --Jakob (Scream about the things I've broken) 12:17, 28 July 2013 (UTC)
And now I believe I fixed the P131/P150 mess. --Jakob (Scream about the things I've broken) 23:55, 29 July 2013 (UTC)


My general statistics pages are updated - now with Wikivoyage

My language, property, statement and namespace statistics are updated. You can see the number of links to each Wikivoyage in the language statistics, and their distibution on namespaces in the namespace statistics. Byrial (talk) 20:53, 29 July 2013 (UTC)

What to do with Category pages

I just created Q14274733 to be used with instance of (P31) on Category pages. Filceolaire (talk) 19:16, 25 July 2013 (UTC)

see Help:Modeling#Wikipedia_categories and maybe put that information there, but I think you just made a duplicate. Or the item listed there is just a subclass ... TomT0m (talk) 19:22, 25 July 2013 (UTC)
Duplicate of Wikimedia category (Q4167836). Michiel1972
We have one for Wikipedia categories, due to that I am going to make the Wikimedia version Wikivoyage specific since one is not available yet and the Wikivoyage categories page is still locally linked. John F. Lewis (talk) 20:49, 25 July 2013 (UTC)
I see no point in having separate items for Wikipedia and Wikivoyage pages as one item like for example Category:Africa (Q5460710) may have sitelinks to both projects. Byrial (talk) 21:44, 25 July 2013 (UTC)
This is premature. See #"Wikipedia disambiguation page" and "Wikipedia category", on this very page. --Izno (talk) 22:11, 25 July 2013 (UTC)
Izno: There seems to me to be a rough consensus to use instance of (P31) to classify these pages (i.e. to link these pages to appropriate classes). What do you think we should do before we get on with it? Filceolaire (talk) 22:36, 25 July 2013 (UTC)
Merge Q14274733 to Q4167836, as this type of consolidation seems natural to me. The same should be done with disambiguation (as it currently is; see Q4167410) and any other such pages. --Izno (talk) 22:44, 25 July 2013 (UTC)
Support. Some items are now "Wikimedia categories" not only "Wikipedia categories". --Infovarius (talk) 17:26, 26 July 2013 (UTC)
There is also a solution not to fusion those items but to make them subclass of MediaWiki categories. This would allow to easily make queries such as which category exists in a Wikivoyage but not in a Wikipedia (if this Category is an instance of both). TomT0m (talk) 18:38, 26 July 2013 (UTC)
Wouldn't those queries fall out naturally, because we might ask "has langlinks of wikivoyage variety but not of wikipedia variety"? (I would expect any query system for our use cases to implement support for "has links of this/that language;this/that project"). I think also that we should try to avoid overly categorizing (heh) pages in this instance, not only because it is functionally useless work for creating a database which primarily supports the world but also because it makes the language links nice, which supports future MediaWiki improvement. As I've argued over at the main page item, being able to jump from one language version of a project to another language version on a completely different project seems like it might actually be very nice. --Izno (talk) 22:47, 26 July 2013 (UTC)
Two classes does not imply two items :) An item can be instance of several classes, so it does not break the ability to make nice interwikis. TomT0m (talk) 23:01, 26 July 2013 (UTC)
Draw me a pretty picture of where exactly you put the interwikis in your scheme. :) --Izno (talk) 23:14, 26 July 2013 (UTC)
Here is the key : one Category in English Wikipedia about England. One Wikiwoyage Category about England. Only one item, two types. The same thing in Manchester Notation :
Individual <England Category>:
     Types : <Wikivoyage category>, <Wikipedia Category>
     Facts : is about <England>
Clearer ? TomT0m (talk) 10:10, 27 July 2013 (UTC)
That does not make it clear where the IWs for lang:Wikivoyage:Categories and lang:Wikipedia:Categories go. Those should still be on the same item. Now what? :) --Izno (talk) 13:40, 27 July 2013 (UTC)
OK, here is the point : there is only one item (Individual stand for instance in Manchester notation) here :) He is instance of both classes (<WP category> and <WD category>). (Another point to advocate for a formal language : once everybody understands it, these kind of misunderstandings should go away) TomT0m (talk) 13:52, 27 July 2013 (UTC)
Outdent: You have not made it clear (regardless of formalism or not) if there are two items for the content (interwikis) currently at the items Q14274733 and Q4167836 in what you propose. Could you do so please? --Izno (talk) 14:08, 27 July 2013 (UTC)
Mmm I'm pretty sure I did several times in several different ways, sorry if it was not clear enough but in wonder how I can do better. Anyway, the thing I did not explicitly say but was implied : <England Category> is, in my Manchester model, the item to which both Wikipedia and Wikivoyage Category pages are linked. TomT0m (talk) 14:18, 27 July 2013 (UTC)
Are there 1 or 2 items for the interwikis? It's that simple. Answer the question please. --Izno (talk) 15:01, 27 July 2013 (UTC)
One. can't do more :p (EDIT but I do, +3 "classes items" <Wikimedia category> <Wikipedia Category> and <Wikivoyage Category>) TomT0m (talk) 15:15, 27 July 2013 (UTC)

Surely one item cannot logically be an instance of both, <Wikivoyage category>, <Wikipedia Category>? Littledogboy (talk) 15:38, 27 July 2013 (UTC)

why not ? I see no real contradiction, to be in a class it is enough to have the logical properties (not this poject properties) of both classes. Here the (logical) properties we want is this category, more precisely ("a category with this subject") exists in Wikipedia (respectively Wikidata). As soon has this item fulfills both of this properties, it can be in both classes. TomT0m (talk) 11:04, 28 July 2013 (UTC)
I thought the idea behind controlled vocabulary was to have strictly defined concepts (labelled with words for human users). So now we are saying a certain category is an instance of categorisation. Great. Littledogboy (talk) 13:11, 30 July 2013 (UTC)

New version of countrymerge

I have updated my program to make countrymerge lists, that is lists which suggest merging of items based on an analysis of links to two Wikipedias containing country names. The previous version found the used country names in a language from the page titles of the Wikipedia pages for the language. Now based on an idea from User:Steenth (thank you, Steen), it will also use other grammatical forms such as adjectives for countries. The method to find other grammatical forms is (simplified):

  1. find all country names in some language like before
  2. find all links to that language with one of the country names
  3. possibly repeat for other languages
  4. find all links to all languages for the items of the found links
  5. find all words in these links and group them after languages and country
  6. take the most frequent words in a language and country combination which are not used in the same language for other countries

That way I have found:

  • English words like Canadian, Japanese, Irish, American, Belgian,
  • German words like Kanadisher, Japanishe, Japanisher, Japanishes, Irischer, Belgischer,
  • French words like canadien, canadienne, japonais, irlandais, irlandaise, américain, américaine, belge,

etc.

As this is based on word frequencies, it will unfortunately also find some wrong words which are not related to the country. The first countrymerge lists (from last evening) made with this new system contained quite a lot strange merge suggestions based on words which were not country related. So I have adjusted the criteria to select words this morning and remade the lists. I will continue to refine the program, and would like to hear your suggestions and comments.

Other changes in the new version are:

  • Now also some states in federations, provinces etc. and more former countries is used. (This gives a problem with Georgia (Q230) vs. Georgia (Q1428) as they have the same name in some languages)
  • It will search for the last match in links instead of the first. That is to be able find Germany instead of German, and Japanese instead of Japan etc.

You will find the lists at User:byrial/countrymerge. I will make for any languages at your request. If you want more details, feel free to study the programs (find_country_adjectives, countrymerge). Byrial (talk) 08:00, 29 July 2013 (UTC)

Once again, some great development, thank you very much. One thing: With the addition of subdivisions, entries like "Mexiko ≠ Yucatán: Q165204 links to de:Mérida (Mexiko) and en:Mérida, Yucatán" appear. Would it add much complexity to let your script accept equality of subdivision and country? --YMS (talk) 09:18, 29 July 2013 (UTC)
It depends on if you call one more table and two dependent subqueries using the new table for much complexity. Anyway I did it, and I also removed Georgia (Q1428) from the search as it gave too much trouble. User:Byrial/countrymerge/de-en is updated. The others are not yet. Byrial (talk) 11:23, 29 July 2013 (UTC)
Fixed a bug where Nigeria could be identified as Niger, Guinea-Bissau as Guinea etc. de-en is updated once more. Byrial (talk) 13:06, 29 July 2013 (UTC)
Very few false candidates in hi-en and gu-en. I will point them out on it's talk page so you can identify them.--Vyom25 (talk) 13:14, 29 July 2013 (UTC)
Thank you. I found and fixed a bug in the adjective finding program because of your report for hi-en. It could wrongly classify words like "Indianapolis" as an alternative form of "Inidiana" giving wrong merge candidates. Byrial (talk) 10:25, 30 July 2013 (UTC)

property 'language'

At moment I'm unable to use the property 'language'. The input field doesn't appear when I'm typing "lang..." and selecting "language" from the dropdown list - the waiting-wheel-icon just turns and turns endless. Tested with IE10 and Chrome2x, logged in and logged out. But only if the display language is "English". I don't have problems when I change to German and select "Sprache". Are someone struggling with this property too? --Nightwish62 (talk) 18:34, 29 July 2013 (UTC)

Sounds like something I have had problems with for every property, all time since Wikidata opened the statments-part. Try to lern the P-names instead, and make a software-update of the patience-part of your brain. -- Lavallen (block) 06:15, 30 July 2013 (UTC)
Looks a little like bugzilla:51575, but that's only when "language" is typed in full. --AVRS (talk) 08:59, 30 July 2013 (UTC)

Number datatype

Any idea when the number datatype is coming out? --Jakob (Scream about the things I've broken) 18:07, 30 July 2013 (UTC)

September https://www.mediawiki.org/wiki/Roadmap#Wikidata_deployment. --Tobias1984 (talk) 19:21, 30 July 2013 (UTC)

Category Topics

I gave Category:Peruvian women writers (Q8759531) three 'category's main topic (P301)s' - 'Peru', 'writer' and 'woman'. Is this right?
Should I have used country (P17), occupation (P106) and sex or gender (P21) as the properties instead? or as well? Filceolaire (talk) 18:26, 30 July 2013 (UTC)

A category item is not an article about a person, so you should not use person-specific claims occupation (P106) and sex or gender (P21). Michiel1972
I think all of these are wrong. P301 is intended to have a unique value (you should only use it to link the item Category:Foo to the item Foo) and P106, P21 should only be used for items about people. Category:Peruvian women writers (Q8759531) is not an item about a group of people, it's an item about a Wikipedia category. 50.100.140.159 19:45, 30 July 2013 (UTC)
category's main topic (P301) Sholuld be something like List of peruvian female writers. JAn Dudík (talk) 05:29, 31 July 2013 (UTC)
country (P17), occupation (P106) and sex or gender (P21) is definitely wrong for categories. --Nightwish62 (talk) 06:55, 31 July 2013 (UTC)

URL-Datatype on Test-Wikidata

Being (hopefully) just one week away of the introduction of URL-Datatype (Wikidata:Project_chat/Archive/2013/06#Short_update_on_URL_datatype) I really wonder why the datatype isn't yet available on the Test-Wikidata? Where is the sense of such test environment, when we didn't use it? Or did this mean, the developers are behind their schedule? --Nightwish62 (talk) 07:06, 31 July 2013 (UTC)

Die Entwicklung ist ein bischen im Verzug (https://www.mediawiki.org/wiki/Roadmap#Wikidata_deployment), aber das ist ja die Erwartungshaltung bei so einem immensen Projekt. --Tobias1984 (talk) 09:56, 31 July 2013 (UTC)

Number datatype

Any idea when the number datatype is coming out? --Jakob (Scream about the things I've broken) 18:07, 30 July 2013 (UTC)

September https://www.mediawiki.org/wiki/Roadmap#Wikidata_deployment. --Tobias1984 (talk) 19:21, 30 July 2013 (UTC)

Category Topics

I gave Category:Peruvian women writers (Q8759531) three 'category's main topic (P301)s' - 'Peru', 'writer' and 'woman'. Is this right?
Should I have used country (P17), occupation (P106) and sex or gender (P21) as the properties instead? or as well? Filceolaire (talk) 18:26, 30 July 2013 (UTC)

A category item is not an article about a person, so you should not use person-specific claims occupation (P106) and sex or gender (P21). Michiel1972
I think all of these are wrong. P301 is intended to have a unique value (you should only use it to link the item Category:Foo to the item Foo) and P106, P21 should only be used for items about people. Category:Peruvian women writers (Q8759531) is not an item about a group of people, it's an item about a Wikipedia category. 50.100.140.159 19:45, 30 July 2013 (UTC)
category's main topic (P301) Sholuld be something like List of peruvian female writers. JAn Dudík (talk) 05:29, 31 July 2013 (UTC)
country (P17), occupation (P106) and sex or gender (P21) is definitely wrong for categories. --Nightwish62 (talk) 06:55, 31 July 2013 (UTC)
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Project_chat/Archive/2013/07&oldid=2123602593"