Wikidata:Contact the development team/Archive/2013/11

UI change: missing focus

When the user added a statement to an item by pressing Enter on the keyboard, the browser used to set the focus on the [add] link. This behavior allowed the user to add the next statement simply by pressing Enter again. After the latest update to the interface, this doesn't happen anymore. Any chance it can be restored? - Soulkeeper (talk) 21:22, 29 October 2013 (UTC)

I'm seeing something similar, where I click [add] (to a claim), and where I simply was able to type, the entry form completely disappears. Probably the same bug. --Izno (talk) 00:34, 30 October 2013 (UTC)

Thanks for the poke. I asked the developer who's working on this to have a look. --Lydia Pintscher (WMDE) (talk) 08:32, 30 October 2013 (UTC)

Patch is being worked on in bugzilla:56296. --Lydia Pintscher (WMDE) (talk) 12:05, 1 November 2013 (UTC)

Roadmap

I have been checking the Wikidata roadmap, but it doesn't seem to be current since September. Could you please update it? I'd like to know how the new plan looks like. Thanks!--Micru (talk) 13:27, 2 November 2013 (UTC)

I'll put it on my todo list to update this. However it's still hard for me to make estimates on a monthly basis like that. But the short version for the next weeks is: numbers datatype, simple queries, ranks. --Lydia Pintscher (WMDE) (talk) 15:57, 4 November 2013 (UTC)

Is special:Search uselang=foo dependend?

Hi! I noticed this since a few days. special:Search|search={{URLENCODE:Mihail Kogălniceanu}}&limit=500&uselang=ro is / might be different then special:Search|search={{URLENCODE:Mihail Kogălniceanu}}&limit=500&uselang=is. It might depend how a newly added page is indexed and might be available first in the language in which it was added. Has anybody experienced this so far?
If so the special:Search at Wikidata should have an additional selection box for the uselang parameter. The value should be preserved the same way as the search string. לערי ריינהארט (talk) 21:31, 4 November 2013 (UTC)

In order not to create duplicates I started to use:

special:ItemByTitle|site=eowiki&uselang=eo

special:ItemByTitle|site=rowiki&uselang=ro

[{{FULLURL:special:ItemByTitle|site=<foo>wiki&uselang=<foo>}} special:ItemByTitle|site=<foo>wiki&uselang=<foo>]

special:ItemByTitle|site=enwiki&uselang=en

It would be great to have a language selection listbox which allows users to change the language easily / automatically. The page can be improved if namespace selection would be supported also. לערי ריינהארט (talk) 13:05, 6 November 2013 (UTC)

Yes these searches are different as they search in the labels of the language you are using the site in. This is intentional. We will look into expanding this using the language fallback that is being worked on. --Lydia Pintscher (WMDE) (talk) 17:41, 6 November 2013 (UTC)

GUI in IE10

The user-interface looks awful for me now, impossible to edit. It looks fine i FF and Chrome. Am I alone? -- Lavallen (talk) 09:40, 5 November 2013 (UTC)

:( Can you upload a screenshot? Anyone else seeing it? --Lydia Pintscher (WMDE) (talk) 09:47, 5 November 2013 (UTC)

Screenshot. -- Lavallen (talk) 10:32, 5 November 2013 (UTC)

The text have I made smaller, to be able to see more than one claim in the Screenshot. There is no edit-buttons, the properties are to the right instead of to the left etc... -- Lavallen (talk) 10:35, 5 November 2013 (UTC)

And this is monobook, vector looks the same. -- Lavallen (talk) 10:36, 5 November 2013 (UTC)

I tried with IE10/W7 and with monobook and vector, and it looks normal here. --Stryn (talk) 11:21, 5 November 2013 (UTC)

Thanks for the screenshot and feedback. I'll have someone here have a look at it. If someone else is also seeing the issue please say so here. --Lydia Pintscher (WMDE) (talk) 17:43, 6 November 2013 (UTC)

Strange error message

Tracked in Bugzilla
Bug 56623

In Aloe ×principis (Q15078580) I tried to change the value of taxon name (P225) from Aloe × principis to Aloe ×principis via UI and got multiple times the message „Failed to get claim from claim Serialization If a hash is present in a reference serialization it needs to be correct“. Whats wrong? --Succu (talk) 13:52, 5 November 2013 (UTC)

I had the same issue, but I was able to work around it by removing the existing claim and re-adding it.[1] It probably had a corrupted reference or something. The Anonymouse (talk) 14:54, 5 November 2013 (UTC)

I found some more items eg. Aloe bakeri × variegata ‘Lysa’ (Q15078282). They have in common that I created, claimed and referenced them via API. --Succu (talk) 15:05, 5 November 2013 (UTC)

Same issue with Q15078581. I can not change the value via UI. I tried to change it with the API and had success (diff). --Succu (talk) 15:45, 5 November 2013 (UTC)

For anyone else looking into this I had a play around with the other entity where the claim couldnt be editing. (all links I am showing are the internal representation). I added a ref, removed it again and then was able to change the claim. So yes, something somewhere is wrong with the left ahnd side and not with the right. And with the message it wouls seem references are getting the wrong hashes somehow...? Looks like the problem resides in the wbsetreference action ·addshore· ^{talk to me!} 17:31, 5 November 2013 (UTC)

retrieved (P813) has the value time="+00000002013-10-18T17:27:48Z" not time="+00000002013-10-18T00:00:00Z". Could this be the cause of the problem? --Succu (talk) 17:46, 5 November 2013 (UTC)

I think so :) See my comment on the bug. Do you know exactly what you passed to the api? ·addshore· ^{talk to me!} 17:49, 5 November 2013 (UTC)

I passed a datetime value formated as "+0000000yyyy-MM-dd'T'HH:mm:ssZ". So all referenced claims of IUCN conservation status (P141) (around 40.000 items) are affected too. :( --Succu (talk) 18:27, 5 November 2013 (UTC)

Yep, after clicking on some random items from the list of what links here for P141 it seems that off of those claims that have this date are affected! So A) this needs to be fixed somewhere in wikibase to stop it happening again. B) we need to go back over all 40,000 claims and 'touch' them fixing the date ;p (unless we can do something internally :). Will take another look at it all in the morning. ·addshore· ^{talk to me!} 18:38, 5 November 2013 (UTC)

Bug about case differences when adding link

There're disambig page da:Ark and da:ARK is a redirect to other page. I added da:Ark to testwikidata:Q210, but the link showing ARK after adding though it is link to Ark in fact. If we click this link, da:Ark will display. Why the link display in page is ARK but not Ark? The ja link of testwikidata:Q211 have the same problem.--GZWDer (talk) 06:05, 8 November 2013 (UTC)

This seems to be working fine for me. Maybe it was a caching issue? --Lydia Pintscher (WMDE) (talk) 15:25, 8 November 2013 (UTC)

Wrong URL in watchlist e-mail?

I got an e-mail today because a data object from my personal watchlist changed. Here is an extract:

"See http://www.wikidata.org/w/index.php?title=Q13358519&diff=0&oldid=44281917 for all changes since your last visit.

Editor's summary: /* wbeditentity-update:0| */Bot: setting proper label for de"

The link in this e-mail does not work. It tells me that I might have found a bug in the software. I can manually check the data object by using a slightly different link: https://www.wikidata.org/w/index.php?title=Q13358519&diff=84438850&oldid=44281917

Maybe it would also be better to generally use https instead of http for links in personal e-mails from wikidata.

--Stefan Weil (talk) 06:14, 8 November 2013 (UTC)

This is tracked in bugzilla:49434. --Lydia Pintscher (WMDE) (talk) 15:28, 8 November 2013 (UTC)

... and the https suggestion is tracked in bugzilla:39676. Thanks, Lydia, for the hint. --Stefan Weil (talk) 10:01, 9 November 2013 (UTC)

Develop a way to query one of several iw links in one wiki site

We need to add more than one site link to oldwikisource, such as there're 141 main pages (140 main pages for 140 languages,and one for the whole sites). It's not easy to query a page in a language in oldwikisource site.

And Wikisource of some languages such as Alemannic and North Frisian is created in a separate namespace in Wikipedia, So we need to add more than one site link in Wikipedia: One for real Wikipedia, and one for Wikisource which is adopted in Wikipedia.--GZWDer (talk) 10:21, 8 November 2013 (UTC)

I am not sure I understand the problem. Can you give me links to examples so I can check them please? --Lydia Pintscher (WMDE) (talk) 15:27, 8 November 2013 (UTC)

1. als and frr Wikisource are merged within Wikipedia. The main page of Alemannic Wikisource is therefor als:Text:Houptsyte and the main page of North Frisian Wikisource is frr:Text:Hoodsid. They can therefor today not be added to Wikimedia main page (Q5296) since that page already contains the main page of Allemanic and North Frisian Wikipedia.

2. Oldwikisource is an Incubator for Wikisource with several main pages in different languages. Inuktitut example. -- Lavallen (talk) 16:23, 8 November 2013 (UTC)

Thank you for the links. I understand now. So we're seeing more and more need for having several links to the same project in one item. This will not happen until the roll-out to Wikisource definitely. It is just too risky and a very disruptive change. Since it will be possible to continue using the old interwiki links in the wikitext I think though this is ok even if not great. (I will however up the priority of us investigating if/how we can make this happen in the future.) The general plan for Wikisource is discussed on Wikidata:Wikisource. I am trying to keep an eye on that too. --Lydia Pintscher (WMDE) (talk) 13:51, 12 November 2013 (UTC)

Empty items -> What links here

WD contains a lot of empty items that are nonetheless useful ("notable") since they are used as a source etc. At the moment the only way to find out is to click on "What links here". Imho it would be helpful to indicate this circumstance on the item page with a hint like: "XY items links here" or or something similar. In other words: It should be possible to see at a glance if a item should deleted. --Kolja21 (talk) 23:03, 12 November 2013 (UTC)

Try out User:Bene*/usage.js. Write importScript( 'User:Bene*/usage.js' ); // [[User:Bene*/usage.js]] into your common.js. Best regards, -- Bene* ^t_a^l_k 23:28, 12 November 2013 (UTC)

Nice, works perfect. --Kolja21 (talk) 00:45, 13 November 2013 (UTC)

@Bene*: A bug: If an item have more then 500 backlinks, "500+" should be shown instead of "500". --GZWDer (talk) 05:36, 13 November 2013 (UTC)

Done thanks for the suggestion. -- Bene* ^t_a^l_k 16:47, 13 November 2013 (UTC)

merging_items_for_Categories_with_items_for_the_Category_topic

Any response on Wikidata:Contact_the_development_team/Archive/2013/10#merging_items_for_Categories_with_items_for_the_Category_topic?

I have not had a chance yet to discuss this unfortunately. Too many other things at the moment :( I'll try to get this done this week. Thanks for poking. --Lydia Pintscher (WMDE) (talk) 15:53, 4 November 2013 (UTC)

So it does not seem impossible but would need a lot more investigation. There are probably a lot of edge cases we didn't think of yet that would break. Given that queries and quantities datatype are currently eating up all the developer time I don't see us making progress on this is the forseeable future. Sorry. --Lydia Pintscher (WMDE) (talk) 15:14, 8 November 2013 (UTC)

Thanks Lydia. The actual question I posted was:

The discussion at Wikidata:Requests for comment/Commons links has generated a proposal which is
getting a lot of support: Merging items for Categories with items for the Category Main Topic. This would
mean that each wikidata item could have two sitelinks to each wikiproject - one to a Category page and
one to another page.
The arguments raised against this are mostly about the technical difficulties associated with doing it. Could
someone in the development team have a look at this discussion and give us some guidance on the technical
implications of making this change?

From your reply I guess that if we want to wait for this feature before we implement sitelinks on Commons then we will be waiting some months, if not years.

Note that this feature (sitelinks from one item to multiple namespaces) will probably also be needed for linking Incubator to Wikidata.

I also remember a comment that some minor language wikis have articles in multiple dialects. This feature will be needed for sitelinks to those wikis. Filceolaire (talk) 19:44, 13 November 2013 (UTC)

Yes. I understand that this is wanted and useful :/ --Lydia Pintscher (WMDE) (talk) 12:23, 14 November 2013 (UTC)

As a side note, it's not wanted universally. :^) --Izno (talk) 01:59, 16 November 2013 (UTC)

HTTP 500 error on Q38

It's only my problem or on Q38 we have HTTP 500 error? --ValterVB (talk) 09:36, 9 November 2013 (UTC)

Not loading here either. We will investigate. Thanks. --Lydia Pintscher (WMDE) (talk) 09:45, 9 November 2013 (UTC)

Update: This seems to be a symptom of a larger underlying issue. We've investigated this since Saturday and started fixing it. I hope we have a fix out with the next deployment. --Lydia Pintscher (WMDE) (talk) 13:44, 12 November 2013 (UTC)

Update 2: The item is accessible again since yesterday. We're still working on fixing the underlying issue though so this doesn't bite us more in the future. --Lydia Pintscher (WMDE) (talk) 12:25, 14 November 2013 (UTC)

Extension to Wikilinks usefull?

Last night I linked a translated article here in wikidata to it´s "mother". However I found several other articles in different languages, obviously different translations of the same articles but in different stages of development. I also do not know, which version was first. I wonder if it is possible to present the number of bytes of the articles with the links, so everybody can see at once which of the articles is more developed and which one is just a stub. It might also help users who want to add properties to find the versions which contain most probably the needed information. It also might encourage authors to enhance existing articles when they can see "there is more to write" or to expand stubs. It allows to compare the quantity also.--Giftzwerg 88 (talk) 13:43, 14 November 2013 (UTC)

This sounds like a good/cool but very niche thing. So I'd say this should be a gadget that people can enable if they want this. I don't want to show things like that for everyone because I am actively trying to reduce the amount of information on a page. We're cluttering it too much already. --Lydia Pintscher (WMDE) (talk) 13:47, 14 November 2013 (UTC)

A button to reveal the information would do also. I sometimes think it should also be possible to hide the property section. Wikilinks and properties are two different things that could have two pages as well.--Giftzwerg 88 (talk) 14:47, 14 November 2013 (UTC)

Yes once we have all the major UI features in place in a few weeks (including ranks and ordering) we'll have a go at rethinking the whole UI. As for your button idea: A button is nice but it is still yet another element in the UI that people have to process when looking at an item. I am trying to reduce this significantly for the benefit of most users and I'd not like to add more things that are only going to be useful to a very small percentage of users. I hope you understand. But as I said: as a gadget that users can enable on-demand this is fine. --Lydia Pintscher (WMDE) (talk) 15:05, 14 November 2013 (UTC)

Don't adapt ppm!

I just read through https://meta.wikimedia.org/wiki/IRC_office_hours/Office_hours_2013-11-13b which refers this page as a base for the units that will be added to Wikidata: http://www.neuron.yale.edu/neuron/static/docs/units/units.dat - I would like to point out, that we shouldn't adapt the measures of concentration in that file because they go against metrological standards. Expressing concentrations in ppm (or ppb or any other magnitude) will result in wrong entries and a lot of ambiguity. For dimensionless number I propose using mathematical numbers, the percent and the per-mil sign. For numbers with dimensions is is absolutely essential that the person inputting the numbers has to choose between µl/l (=ppm), µg/g (=ppm), µmol/mol (=ppm), µm/m (=ppm), .... (The UI also needs to handle mixed concentrations like µg/l or mol/l.) - That way everybody knows if e.g. volume or mass is meant. --Tobias1984 (talk) 10:20, 14 November 2013 (UTC)

Tobias1984: we are discussing on this rfc about which units are needed. It would be great if you could add those units for the dimension "concentration" (it doesn't exist yet).--Micru (talk) 10:34, 14 November 2013 (UTC)

Ups, didn't see that one. I will make a table ;) --Tobias1984 (talk) 10:44, 14 November 2013 (UTC)

Thanks for the feedback! As Daniel wrote there it would be most helpful if we could get a list out of that rfc of the most urgent units. Initially we will not have everything and it would be good to get an idea of what we should concentrate on first. Getting a list of all units out there is not so useful at the beginning. --Lydia Pintscher (WMDE) (talk) 12:30, 14 November 2013 (UTC)

Hi Lydia. The RfC already has reached a point were some comments from a relevant developer would be helpful. Can somebody review the comment section and the talk page? Thanks. --Tobias1984 (talk) 15:18, 19 November 2013 (UTC)

Thanks for the poke. I'll try to get to it tomorrow. --Lydia Pintscher (WMDE) (talk) 17:28, 19 November 2013 (UTC)

Can not remove P107 in Q101 because of length constraint

Please fix it.--GZWDer (talk) 10:38, 19 November 2013 (UTC)

Adam is looking into it. Thanks. --Lydia Pintscher (WMDE) (talk) 17:29, 19 November 2013 (UTC)

RE: GUI in IE10

Regarding: Wikidata:Contact the development team/Archive/2013/11#GUI in IE10.

My computer have updated to IE 11, who do not have the same problems. -- Lavallen (talk) 08:16, 21 November 2013 (UTC)

xml format is changed?

In test.wikidata.org when I use "wbgetentities" the xml is

<entities><Q14 pageid="117" ns="0" title="Q14" lastrevid="2419" modified="2013-11-22T19:09:23Z" id="Q14" type="item">.... without <entity pageid="138" ...>

It's a new version, or an error? --ValterVB (talk) 20:24, 22 November 2013 (UTC)

This is an error. Thanks so much for catching it. We need to fix it before deploying. I've filed bugzilla:57529. --Lydia Pintscher (WMDE) (talk) 10:52, 25 November 2013 (UTC)

internal_api_error_MWException on test.wikidata.org

I tried to add quantity to a property with bot but I have error: <error code="internal_api_error_MWException" info="Exception Caught: Internal error in ApiFormatXml::recXmlPrint: (P10, ...) has integer keys without _element value. Use ApiResult::setIndexedTagName()." xml:space="preserve" />. This is the claim that I want add:

{
	"claims" : [{
			"mainsnak" : {
				"snaktype" : "value",
				"property" : "P69",
				"datavalue" : {
					"value" : {
						"amount" : "+1000",
						"unit" : "1",
						"upperBound" : "+1001",
						"lowerBound" : "+999"
					},
					"type" : "quantity"
				}
			},
			"type" : "statement",
			"rank" : "normal"
		}
	]
}

My error or some problem in API? --ValterVB (talk) 10:41, 23 November 2013 (UTC)

However the claim is recorded in database. --ValterVB (talk) 09:31, 24 November 2013 (UTC)

Thanks a lot! We have to fix this one as well. I have filed bugzilla:57531. --Lydia Pintscher (WMDE) (talk) 11:07, 25 November 2013 (UTC)

Which Api module are you using? ·addshore· ^{talk to me!} 11:40, 25 November 2013 (UTC)

"wbeditentity", if you need more detail, I'll copy and past this evening the complete HTTP request. --ValterVB (talk) 12:39, 25 November 2013 (UTC)

If you still have it that will be perfect :) Then I should be able to reproduce it in the same way. ·addshore· ^{talk to me!} 13:05, 25 November 2013 (UTC)

Tested now:

URL:https://test.wikidata.org/w/api.php?action=wbeditentity&format=xml

POST data (plain text):

id=Q14&token=0e74ef4d1a37aca646b8cadcbf44d12d+\&bot=bot&data={"claims":[{"mainsnak":{"snaktype":"value","property":"P69","datavalue":{"value":{"amount":"+0","unit":"+0", "upperBound":"+0", "lowerBound":"+0"},"type":"quantity"}},"type":"statement","rank":"normal"}]}&summary=Bot:Test quantity

POST data (encoded):

id=Q14&token=0e74ef4d1a37aca646b8cadcbf44d12d%2b%5c&bot=bot&data=%7b%22claims%22%3a%5b%7b%22mainsnak%22%3a%7b%22snaktype%22%3a%22value%22%2c%22property%22%3a%22P69%22%2c%22datavalue%22%3a%7b%22value%22%3a%7b%22amount%22%3a%22%2b0%22%2c%22unit%22%3a%22%2b0%22%2c+%22upperBound%22%3a%22%2b0%22%2c+%22lowerBound%22%3a%22%2b0%22%7d%2c%22type%22%3a%22quantity%22%7d%7d%2c%22type%22%3a%22statement%22%2c%22rank%22%3a%22normal%22%7d%5d%7d&summary=Bot%3aTest+quantity

--ValterVB (talk) 18:53, 25 November 2013 (UTC)

Added to bugzilla] --ValterVB (talk) 18:56, 25 November 2013 (UTC)

Two suggestion about quantities datatype

@Lydia Pintscher (WMDE)::

Scientific notation should be supported because it's hardly to count the number of 0's in so big a number like 100000000000000000000000000000000000000000000000000000000000000000000000000000000 (one googol)
We should choose whether "+" be omitted or not.

--GZWDer (talk) 15:41, 23 November 2013 (UTC)

For the + it would be enough to show it if it is explicitly typed, and keep it hidden otherwise. My two other wishes:

prefixes: ± (specially for new properties like "standard deviation"), <, ≤, ≥, > (to remove or to max the upper or lower bound), ≈ (for irrational numbers, even with 10^{126} digits the value it is still an approximation).
fractions: maybe lower priority but still useful.--Micru (talk) 15:59, 23 November 2013 (UTC)

Can't the points made with prefixes be expressed with qualifiers? --Avenue (talk) 22:25, 23 November 2013 (UTC)

If we use a a number datatype property as a qualifier (for instance: "std deviation"), it needs the ±, there are no "qualifiers of qualifiers".--Micru (talk) 01:44, 24 November 2013 (UTC)

That's a fair point, although I think the "±" aspect would also be implicit in the nature of a "standard deviation" property (and of other symmetric measures of uncertainty). So displaying the "±" sign within Wikidata for such properties seems unnecessary to me. The other prefixes seem less likely to be used within qualifiers.

Fractions are important in some domains (e.g. screw threads based on standards like Unified Thread Standard (Q1579138)). They seem a higher priority than the prefixes to me, although I think neither is nearly as important as scientific notation. --Avenue (talk) 07:32, 24 November 2013 (UTC)

± already exists. If you ask a api-question to one of the items on test.wikidata.org, you will see that the data always have a upperBound value and a lowerBound value. That means that the population of Q34 is 300000000 ± 1 (299999999-300000001).

But that is not the same thing as a standard deviation. -- Lavallen (talk) 08:37, 24 November 2013 (UTC)

A few of those things are simply missing the formatter which needs to be finished before we launch it here. I hope I can update you with more details soon but I need to talk to Daniel first on what is done and what not. --Lydia Pintscher (WMDE) (talk) 11:12, 25 November 2013 (UTC)

I've filed bugzilla:57588 for the scientific notation and bugzilla:57589 for the + being kept for certain properties. --Lydia Pintscher (WMDE) (talk) 13:49, 26 November 2013 (UTC)

Statements about properties

A while ago there was a discussion about statements about properties. Since then WMF legal have published meta:Wikilegal/Database Rights which includes the advice that:

For EU databases, bots or other automated ways of extracting data should also be avoided
because of the Directive’s prohibition on “repeated and systematic extraction” of even insubstantial amounts of data.

This suggests another couple of statements we need to be able to make about our authority control properties and other properties that refer to databases.

License terms
Place of publication

Filceolaire (talk) 23:09, 22 November 2013 (UTC)

Some time ago it was decided that the best place to store property metadata was on the property page itself with statements. License info also could go there (using copyright license (P275)). The thing is that property pages do not accept statements, that's why we haven't processed yet some other related properties (for instance these or this). Is there any difficulty in unlocking property pages for adding statements?--Micru (talk) 08:40, 23 November 2013 (UTC)

According to Lydia, meta-properties depend on bugzilla:49554. I will copy this conversation to Wikidata:Property proposal/Pending/4 (properties depending on the bug) for future reference.--Micru (talk) 15:31, 23 November 2013 (UTC)

Yes we will have statements on property pages. But I am absolutely sure we should not use them for what you propose. (Unless I am misunderstanding what you're trying to do.) All data in Wikidata is CC-0. If we start licensing some of it in a different way this will be really really bad and a huge pain for anyone re-using the data. Place of publication is a source and should go with the data point in the item where the statement is. --Lydia Pintscher (WMDE) (talk) 11:00, 25 November 2013 (UTC)

Are you a lawyer, to be so sure that what WMF lawyers seem to be saying is wrong? We want to store a wide range of data in Wikidata, some of which is clearly not CC-0 in its source jurisdiction. Failing to store relevant licensing information is what will cause huge pain to re-users. --Avenue (talk) 20:13, 26 November 2013 (UTC)

My point is that this data shouldn't be imported in the first place if it can't be published as CC-0. --Lydia Pintscher (WMDE) (talk) 11:09, 27 November 2013 (UTC)

Okay, I think that's a coherent position to take, although it seems like it would greatly restrict Wikidata's scope. Let me check I understand with some examples. Are you saying that we shouldn't be systematically importing VIAF identifiers (currently stored using the VIAF ID (P214) property), because this data is available under the Open Data Commons (Q2025635) Attribution license (ODC-By 1.0)[2] but not CC-0? Do you also mean we shouldn't import census population figures for UK counties etc (when the quantity data type becomes available) because this data is licensed under the Open Government License 1.0,[3] not CC-0? --Avenue (talk) 12:15, 27 November 2013 (UTC)

As the Foundation's paper on this explained there is a difference between importing large amounts of data and only parts when it comes to being able to publish the result as CC-0. --Lydia Pintscher (WMDE) (talk) 13:36, 27 November 2013 (UTC)

True, and what counts as a "large" or "substantial" part of a database is open to interpretation. We currently have over 400,000 items using VIAF ID (P214), which seems like a large amount, but is only 2% of the 20 million clusters in VIAF.[4] If our use of VIAF is governed by US law (not EU law), maybe we aren't breaking their copyright (and so don't need to follow the ODC license conditions), although it could be arguable either way.

For EU databases, the legal constraints are more stringent, as the WMF's legal paper notes. Going back to the UK example, English Wikipedia has lists like w:List of English districts by population and templates like w:Template:English district population that contain population data on English districts. But these contain a substantial part (about one quarter) of the data published in the ONS's Table 8a Mid-2011 Population Estimates: Selected age groups for local authorities in England and Wales; estimated resident population. This has been released under the OGL 1.0, which requires attribution in a certain form and (where possible) linking to the license.

The WMF's legal paper concludes that it's best to use such EU data only if it is released under an open license that covers database rights. The clear implication is that if we host this data, we should follow the license conditions. If Wikidata will only accept data published under CC-0, this will rule out a lot of useful data that is available under other open licenses. --Avenue (talk) 23:42, 27 November 2013 (UTC)

On second thought, this is getting off topic, as much of the necessary licensing details would not apply to entire properties. The broad topic of database rights and licenses is also more a question for the community than the development team. Sorry, feel free to ignore my posts above. --Avenue (talk) 13:40, 29 November 2013 (UTC)

http or https?

In type "globecoordinate" globe normally is "http://www.wikidata.org/entity/Q2" maybe is better change in "https://..." ? --ValterVB (talk) 19:42, 26 November 2013 (UTC)

Yes we should change this but still accept the old ones to not break anything. Can you please file a bug for that on bugs.wikimedia.org? Thank you! --Lydia Pintscher (WMDE) (talk) 11:24, 27 November 2013 (UTC)

Actually forget that. Daniel already did ;-) It's bugzilla:57644. --Lydia Pintscher (WMDE) (talk) 11:24, 27 November 2013 (UTC)