Property talk:P856
If you can't add this property with links, the links you tried to enter may be affected by Meta-Wiki Spam blacklist, this is a known problem of the Wikibase software, and we are still considering the solution, please do not ask here to unblacklist them, as Wikidata.org is not currently able to circumvent this.
Per m:Talk:Spam blacklist/Recurring requests, an unblacklist request on Meta-Wiki that is just for the purposes of Wikidata will likely be rejected, but you may request certain subpages of sites (like /about, /index.php, etc.) to be whitelisted, note that this may only help you to enter URL statements other than P856. In general, this is tracked at User:Trade/Spam-blacklist whitelist and phab:T243484. |
Documentation
URL of the official page of an item (current or former). Usage: If a listed URL no longer points to the official website, do not remove it, but see the "Hijacked or dead websites" section of the Talk page
Description | URL to the official website of this item | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Represents | official website (Q22137024), home page (Q11439) | ||||||||||||
Has quality | official (Q29509043) | ||||||||||||
Data type | URL | ||||||||||||
Corresponding template | Template:Official website (Q5614958), Template:Wikidata/P856 (Q17142840), Template:Official URL (Q19921795) | ||||||||||||
Domain | organisations, persons, etc. (note: this should be moved to the property statements) | ||||||||||||
Allowed values | (https?|ftps?)://\S+(?i)((?!\b(://web\.archive\.org/)).)*^((?!google\.com/search\?).)*$^(?!https?://www\.$).+ | ||||||||||||
Usage notes | If an official homepage changes, add an additional statement with preferred rank. Do not remove the former URL. For active WMF sites, please use P4174. | ||||||||||||
Example | Facebook (Q355) → https://www.facebook.com Daikin Industries (Q1157589) → http://www.daikin.co.jp Intel (Q248) → https://www.intel.com/content/www/us/en/homepage.html Mort Fertel (Q109483424) → https://marriagemax.com | ||||||||||||
Tracking: same | Category:Official website is in Wikidata (Q18595774) | ||||||||||||
Tracking: differences | Category:Official website different in Wikidata and Wikipedia (Q18929423) | ||||||||||||
Tracking: usage | Category:Pages using Wikidata property P856 (Q15886160) | ||||||||||||
Tracking: local yes, WD no | Category:Official website not in Wikidata (Q19930391) | ||||||||||||
See also | official blog URL (P1581), stated in (P248), imported from Wikimedia project (P143), website account on (P553), house publication (P2813), described at URL (P973), exact match (P2888), curriculum vitae URL (P8214), terms of service URL (P7014), charter URL (P6378), privacy policy URL (P7101), official shop URL (P10225), contact page URL (P11266), official jobs URL (P10311), official wiki URL (P12203), search formatter URL (P4354) | ||||||||||||
Lists | |||||||||||||
Proposal discussion | Proposal discussion | ||||||||||||
Current uses |
| ||||||||||||
Search for values |
List of violations of this constraint: Database reports/Constraint violations/P856#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#single best value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#Item P31, SPARQL
(?i)((?!\b(://web\.archive\.org/)).)*
”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P856#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#mandatory qualifier, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#Entity types
List of violations of this constraint: Database reports/Constraint violations/P856#Unique value, SPARQL (every item), SPARQL (by value)
^((?!google\.com/search\?).)*$
”: value must be formatted using this pattern (PCRE syntax). (Help)List of violations of this constraint: Database reports/Constraint violations/P856#Format, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P856#Format, SPARQL
Ensure urls for active WMF sites include https and trailing slash. Sample: https://en.wikipedia.org/ not http://en.wikipedia.org/ or https://en.wikipedia.org (Help)
Violations query:
SELECT DISTINCT ?item (str(?s) as ?s1) { { ?item wdt:P279/wdt:P31* wd:Q14827288 } UNION { ?item wdt:P137 \u007C wdt:P127 wd:Q180 } ?item wdt:P856 ?s OPTIONAL { ?item wdt:P576 ?closed } FILTER(!BOUND(?closed)) FILTER( strafter(str(?s),".org") != "/" \u007C\u007C strstarts(str(?s),"http:") ) }
List of this constraint violations: Database reports/Complex constraint violations/P856#Active WMF sites
Vast majority of sites would handle www. prefix for users. Very rare
Violations query:
SELECT ?item ?value { ?item wdt:P856 ?value FILTER(STRSTARTS(STR(?value), "https://www.") \u007C\u007C STRSTARTS(STR(?value), "http://www.")) } LIMIT 10
List of this constraint violations: Database reports/Complex constraint violations/P856#to www or not to www
(Help)
Violations query:
SELECT ?item { ?item wdt:P31 wd:Q35127 . MINUS { ?item wdt:P856 [] } } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P856#Websites should have this property
(Help)
Violations query:
SELECT ?item { ?item wdt:P31 wd:Q186165 . MINUS { ?item wdt:P856 [] } } LIMIT 100
List of this constraint violations: Database reports/Complex constraint violations/P856#Webportals should have this property
Pattern ^[Hh][Tt][Tt][Pp](s?)://W[Ww][Ww]\.(.+)$ will be automatically replaced to http\1://www.\2. Testing: TODO list |
Pattern ^https?://(www\.)?plus\.google\.com/(\d{21}|\+[-\w_À-ÿА-я]+|communities/\d{21})(/(about(\?hl=en)?)?)?$ will be automatically replaced to \2 and moved to Google+ ID (P2847) property. Testing: TODO list |
Pattern ^https?://(www\.)?twitter\.com/([A-Za-z0-9_]{1,15})/?$ will be automatically replaced to \2 and moved to X username (P2002) property. Testing: TODO list |
Pattern ^https?://(www\.)?instagram\.com/([a-z0-9_\.]+)/?$ will be automatically replaced to \2 and moved to Instagram username (P2003) property. Testing: TODO list |
Pattern ^https?://(www\.)?youtube\.com/channel/(UC([A-Za-z0-9_\-]){22})/?$ will be automatically replaced to \2 and moved to YouTube channel ID (P2397) property. Testing: TODO list |
Pattern ^https?://(www\.)?vk\.com/([A-Za-z0-9_\.]{2,32})/?$ will be automatically replaced to \2 and moved to VK ID (P3185) property. Testing: TODO list |
Pattern ^https?://(www\.)?linkedin\.com/in/([\-\&%A-Z0-9a-záâãåäăąćčçéèêěëğîıíłńñøóòôöõřśşșšțúůüýž]+)/?$ will be automatically replaced to \2 and moved to LinkedIn personal profile ID (P6634) property. Testing: TODO list |
Pattern ^https?://(www\.)?ameblo\.jp/([a-z0-9-]{3,24})/?$ will be automatically replaced to \2 and moved to Ameblo username (P3502) property. Testing: TODO list |
Pattern ^https?://(www\.)?medium\.com/([A-Za-z0-9_\.]{1,30})/?$ will be automatically replaced to \2 and moved to Medium username (P3899) property. Testing: TODO list |
Pattern ^https?://(www\.)?facebook\.com/([\p{L}\d.-]+)/?$ will be automatically replaced to \2 and moved to Facebook username (P2013) property. Testing: TODO list |
Pattern ^https?://(www\.)?facebook\.com/pages/([\p{L}\d.-]+/[1-9][0-9]+)/?(\?f?ref=[a-z_]+)?(\?sk=info&tab=page_info)?$ will be automatically replaced to \2 and moved to Facebook page ID (P4003) property. Testing: TODO list |
Pattern ^https?://(www\.)?yerelnet\.org\.tr/koyler/koy\.php\?koyid=([2-9]\d{5})$ will be automatically replaced to \2 and moved to YerelNet village ID (P2123) property. Testing: TODO list |
Pattern ^https?://(www\.)?lineblog\.me/([a-z0-9_]+)/?$ will be automatically replaced to \2 and moved to Line Blog user ID (P7211) property. Testing: TODO list |
Pattern ^(https?://www\.[a-z]+\.com)/?\.$ will be automatically replaced to \1. Testing: TODO list |
Pattern ^(https?://www\.[a-z]+\.com)/?,$ will be automatically replaced to \1. Testing: TODO list |
Pattern ^(https?):///(www\..+)$ will be automatically replaced to \1://\2. Testing: TODO list |
Pattern ^https?://(?:sp\.)?seiga\.nicovideo\.jp/(comic/\d+)[^\d]*$ will be automatically replaced to \1 and moved to Niconico ID (P11176) property. Testing: TODO list |
Pattern ^https?://bookwalker\.jp/series/(\d+)$ will be automatically replaced to \1 and moved to BookWalker series ID (JP version) (P11259) property. Testing: TODO list |
Pattern ^https?://comic-walker\.com/contents/detail/(KDCW_[A-Z]{2}\d{2}[012]0\d{4}0[123]0000_68)/?$ will be automatically replaced to \1 and moved to ComicWalker content ID (P11501) property. Testing: TODO list |
Pattern ^https?://ncode\.syosetu\.com/(n\d{4}[a-z]{1,2})/?$ will be automatically replaced to \1 and moved to Shōsetsuka ni Narō work ID (P11335) property. Testing: TODO list |
Pattern ^https?://x?mypage\.syosetu\.com/([1-9]\d*|x\d{4}[a-z]{2})/?$ will be automatically replaced to \1 and moved to Shōsetsuka ni Narō user ID (P11441) property. Testing: TODO list |
Pattern ^https?://comic\.pixiv\.net/works/(\d+)$ will be automatically replaced to \1 and moved to pixiv comic work ID (P11543) property. Testing: TODO list |
Pattern ^https?://note\.com/([\da-z_]+)/?$ will be automatically replaced to \1 and moved to note.com user ID (P11401) property. Testing: TODO list |
Pattern ^https?://store\.steampowered\.com/app/([1-9]\d{0,6})(?:[^\s]+)?/?$ will be automatically replaced to \1 and moved to Steam application ID (P1733) property. Testing: TODO list |
Pattern ^(https?://(?:[a-z\d\-\_]+)\.itch\.io/[a-z\d\-\_]+)/?$ will be automatically replaced to \1 and moved to itch.io URL (P7294) property. Testing: TODO list |
Pattern ^https?://gamejolt\.com/games/[\w-_]+/([\d+]+)/?$ will be automatically replaced to \1 and moved to Game Jolt game ID (P12072) property. Testing: TODO list |
Pattern ^https?://play\.google\.com/store/apps/details\?(?:hl=.+&)?id=([a-zA-Z0-9_]+(?:\.[a-zA-Z0-9_]+)+)$ will be automatically replaced to \1 and moved to Google Play Store app ID (P3418) property. Testing: TODO list |
Pattern ^https?://(?:www\.)?roblox\.com/games/(\d+)(?:/?(?:.+))?$ will be automatically replaced to \1 and moved to Roblox experience ID (P11548) property. Testing: TODO list |
wrong category
[edit]Hi! This page is in Category:Properties with iri-datatype. It should be in Category:Properties with url-datatype. לערי ריינהארט (talk) 11:50, 2 December 2013 (UTC)
Only for organisations?
[edit]On top of this discussion page there is said that this property should only be used for organisations. A quick search shows that persons like Ken Jennings, Larry Sanger or Stanley Kubrick also own this property. Are they exceptions to the rule or can this property be used for all persons? -- Köllner (talk) 14:09, 23 December 2014 (UTC)
- It can be used by organizations, persons etc. I think it was just copypasted from somewhere. As stated on Property:P856: "URL to the website of this item", is correct. --Stryn (talk) 14:34, 23 December 2014 (UTC)
- Fixed now. Stryn (talk) 14:36, 23 December 2014 (UTC)
- Regarding 'etcetera', the property has also been added to Nativity of St. John the Baptist (Q18602467), pointing to the official description of the painting by the museum which holds it. I think that's official enough. :-) Bever (talk) 12:26, 12 June 2015 (UTC)
- Fixed now. Stryn (talk) 14:36, 23 December 2014 (UTC)
Add archive URL (P1065) to list of qualifiers
[edit]I propose to add https://www.wikidata.org/wiki/Property:P1065 to the list of qualifiers. I think this will be more common as more dead links are found and to change P856 to a link in web.archive.org (official website) is not the best option. Carlos Porto (talk) 22:02, 15 October 2015 (UTC)
Internet Archive
[edit]Should we provide URL at archive.org for official website that is dead, or not? For instance as I revised Peter Maddocks Q7175598 moments ago.
If so, should we qualify somehow, perhaps with archivedate? --P64 (talk) 22:50, 18 October 2015 (UTC)
Single value constraint
[edit]What is the thinking behind the constraint limiting this to a single value? There are at present over 2000 violations of this, which from the small sample I looked at all seem to be correct - mostly different websites for different countries and/or languages. Thryduulf (talk: local | en.wp | en.wikt) 23:27, 29 May 2016 (UTC)
- They are probably false positive, yes. The use you see in for example #Q20#P856, even if I haven't checked the pages, probably correct. You can add exceptions to the template above, and those cases will not appear in the reports. -- Innocent bystander (talk) 11:14, 3 June 2016 (UTC)
- We should probably have a complex constraint here: for all entities where official website is used and where there is only one claim, no language is necessary. Where official website is used and where there is more than one claim, you must use language as a qualifier (and if it's possible, the language as a qualifier should only appear in the context of a single claim). I thought we had a complex constraint template lying around...? --Izno (talk) 11:49, 3 June 2016 (UTC)
- Some companies can have an official homepage distributed to different to clients in different nations. I often visit the homepage of Deutsche Bank, and they have a special homepage for Sweden, since not all of or their products can be marketed here. -- Innocent bystander (talk) 12:37, 3 June 2016 (UTC)
- They may be serving that to you automatically... So far as I know, no client wikis have templates that do anything more than check to see if there is a language qualifier. --Izno (talk) 13:02, 3 June 2016 (UTC)
- In this specific case, they don't, it is probably a legal matter. If I tell the page I live in the US, I am denied access to the page. But you are probably right, and since (almost) all wikis are only pov according to their language(s), not their nation, language is the most important qualifier. The module I have been hacking on svwiki priorities claims with language=Swedish as qualifier by default. -- Innocent bystander (talk) 13:49, 3 June 2016 (UTC)
- They may be serving that to you automatically... So far as I know, no client wikis have templates that do anything more than check to see if there is a language qualifier. --Izno (talk) 13:02, 3 June 2016 (UTC)
- Official websites can also be distinguished by target audience rather than by language, e.g. the various national editions of Google Search (Q9366) or personal vs business customers (I think Lloyds Bank (Q1152847) does this) so a complex constraint would need to I think allow qualifiers language of work or name (P407), applies to jurisdiction (P1001) or intended public (P2360). Thryduulf (talk: local | en.wp | en.wikt) 16:15, 3 June 2016 (UTC)
- Sure; my suggestion was a sketch. --Izno (talk) 16:23, 3 June 2016 (UTC)
- Some companies can have an official homepage distributed to different to clients in different nations. I often visit the homepage of Deutsche Bank, and they have a special homepage for Sweden, since not all of or their products can be marketed here. -- Innocent bystander (talk) 12:37, 3 June 2016 (UTC)
It seems that it has been established here there are several reasons why an item may have more than one official website. Should the single value constraint therefore simply be removed or is there a desire to craft a complex constraint? If the latter is anyone working on it? Thryduulf (talk) 08:11, 15 June 2016 (UTC)
- @Izno: Are you talented with such know-how? -- Innocent bystander (talk) 08:14, 15 June 2016 (UTC)
- We need to see if there is even a thing such as a complex constraint. And I'm not the know-how guy in this case; someone who has a finer skill at SQL will probably need to help :D. --Izno (talk) 10:48, 15 June 2016 (UTC)
{{Complex constraint}}
? It seems the constraints you want are some kind of "guarded constraints", of the form "if guard then constraint". This is writable in sparl with the formselect ?item where { select all items who matches the guard minus select all the items that matches the constraint
orselect ?item where { select all items who matches the guard where not exists items that do not matchconstraint
, for example. I guess I could write a Category:Partial query to help to express such guarded stuffs. author TomT0m / talk page 14:50, 15 June 2016 (UTC)- I don't really understand your terminology, but I think what we want is "if there are multiple values, then all values should have one of the qualifiers language of work or name (P407), applies to jurisdiction (P1001) or intended public (P2360)". Ideally with an easy way to add other allowed qualifiers if found to be needed. Thryduulf (talk) 12:17, 16 June 2016 (UTC)
- I'll work on it. author TomT0m / talk page 17:14, 16 June 2016 (UTC)
- PS: with a correction of the link it should be easier to understand :) author TomT0m / talk page 17:16, 16 June 2016 (UTC)
- Ivan: I think you already have a solution for this (ignore single value constraint violations when a qualifier distinguishes them), would you activate it for the P18 report?
--- Jura 05:09, 17 June 2016 (UTC)- Worked a little bit this morning on a few templates, here is the state of my work : Can someone confirm this actually works ? The final query does not returns any results right now, which would mean there is not any violation which would be surprising.Here is the query written by the help of templates :
select ?item where { {{IfThenConstraint # if then selects all the items which are selected by the "if" and removes all those who do match the "then". The result is supposed to be the constraint violation. |if={{Multiple values|official website|?item}} #"multiple values" selects all the items with several official website claims ?item ps:P586 ?websitestatement. #this line selects all those statements |then={{qualified by|?websitestatement|P407,P1001,P2360}} #"qualified by" filters the statemetnts who are qualified by any of P401, P1001 and P2360 }} }
Here is the resulting query :Try it!select ?item where { { ?item wdt:P856 ?item_official_website_val1, ?item_official_website_val2 filter(?item_official_website_val1 != ?item_official_website_val2) . ?item ps:P586 ?websitestatement. } filter not exists { ?websitestatement ?websitestatementqualifier ?websitestatementqualifiervalue . values ?websitestatementqualifier { pq:P407 pq:P1001 pq:P2360 } } }
- author TomT0m / talk page 10:20, 17 June 2016 (UTC)
- Worked a little bit this morning on a few templates, here is the state of my work : Can someone confirm this actually works ? The final query does not returns any results right now, which would mean there is not any violation which would be surprising.
- Ivan: I think you already have a solution for this (ignore single value constraint violations when a qualifier distinguishes them), would you activate it for the P18 report?
- I don't really understand your terminology, but I think what we want is "if there are multiple values, then all values should have one of the qualifiers language of work or name (P407), applies to jurisdiction (P1001) or intended public (P2360)". Ideally with an easy way to add other allowed qualifiers if found to be needed. Thryduulf (talk) 12:17, 16 June 2016 (UTC)
Please normalize?
[edit]@Jura1: What is your instruction supposed to mean? That we should prefer HTTPS? Or...? --Izno (talk) 11:30, 14 June 2016 (UTC)
- Use https://en.wikipedia.org/ not http://en.wikipedia.org/ or https://en.wikipedia.org
--- Jura 11:31, 14 June 2016 (UTC)- Why is the instruction related only to the WMF? --Izno (talk) 11:46, 14 June 2016 (UTC)
- Not every website supports https, and whether domain.com and domain.com/ are the same is not predictable (I guess it depends on the configuration of the web server). Thryduulf (talk) 17:29, 14 June 2016 (UTC)
- I added that as WQS outputs them that way for sitelinks.
--- Jura 18:02, 14 June 2016 (UTC) - Just as a side note: strictly speaking URLs of the form http://example.com do not exist, but all existing web browsers assume this to mean http://example.com/. The server is not involved. (There is no way to request the empty path in HTTP.) --Srittau (talk) 20:01, 14 June 2016 (UTC)
- That's why I was asking; I was pretty certain that was the case. @Jura1: We can probably relax that to "use the trailing slash after the domain" and "prefer HTTPS where possible" broadly, rather than the more specific "WMF-only" instruction. --Izno (talk) 10:50, 15 June 2016 (UTC)
- @Jura1 Hi, can you show me an example about "WQS outputs them that way for sitelinks"? @Izno Why should we add a trailing slash? The URL for Google is: http://www.google.com not http://www.google.com/. --Rotpunkt (talk) 12:52, 15 June 2016 (UTC)
- @Rotpunkt: Here is one. Maybe it could be generalized, but I'd rather see it formulated separately for WQS/WMF.-- Jura 13:05, 15 June 2016 (UTC)
- @Jura I don't understand why you refer to WQS. They appear with a trailing slash just because their P856 has a trailing slash.--Rotpunkt (talk) 13:25, 15 June 2016 (UTC)
- Here is a more explicit sample: [1]. To make it work, I temporarily removed the trailing slash for vecwiki.
--- Jura 13:33, 15 June 2016 (UTC) - @Rotpunkt: review Srittau's comment. --Izno (talk) 13:34, 15 June 2016 (UTC)
- @Jura Indeed a basic query returns it without trailing slash. @Izno are you referring to << all existing web browsers assume this to mean http://example.com/ >>. So? We are just writing URLs, not URLs as they were transformed by browsers. Is there a W3C recommendation that says we should write http://www.facebook.com/ instead of http://www.facebook.com? --Rotpunkt (talk) 13:58, 15 June 2016 (UTC)
RFC 2616 (HTTP/1.1) in conjunction with RFC 3986 (URIs) says exactly that. Non-relative HTTP URIs use an absolute path, which starts with a slash. --Srittau (talk) 23:20, 15 June 2016 (UTC)Actually, the abs_path is optional, and if left out the URI is equivalent to abs_path of "/". --Srittau (talk) 23:25, 15 June 2016 (UTC)
- @Jura Indeed a basic query returns it without trailing slash. @Izno are you referring to << all existing web browsers assume this to mean http://example.com/ >>. So? We are just writing URLs, not URLs as they were transformed by browsers. Is there a W3C recommendation that says we should write http://www.facebook.com/ instead of http://www.facebook.com? --Rotpunkt (talk) 13:58, 15 June 2016 (UTC)
- Here is a more explicit sample: [1]. To make it work, I temporarily removed the trailing slash for vecwiki.
- @Jura I don't understand why you refer to WQS. They appear with a trailing slash just because their P856 has a trailing slash.--Rotpunkt (talk) 13:25, 15 June 2016 (UTC)
- @Rotpunkt: Here is one. Maybe it could be generalized, but I'd rather see it formulated separately for WQS/WMF.-- Jura 13:05, 15 June 2016 (UTC)
- @Jura1 Hi, can you show me an example about "WQS outputs them that way for sitelinks"? @Izno Why should we add a trailing slash? The URL for Google is: http://www.google.com not http://www.google.com/. --Rotpunkt (talk) 12:52, 15 June 2016 (UTC)
- That's why I was asking; I was pretty certain that was the case. @Jura1: We can probably relax that to "use the trailing slash after the domain" and "prefer HTTPS where possible" broadly, rather than the more specific "WMF-only" instruction. --Izno (talk) 10:50, 15 June 2016 (UTC)
- I added that as WQS outputs them that way for sitelinks.
- Not every website supports https, and whether domain.com and domain.com/ are the same is not predictable (I guess it depends on the configuration of the web server). Thryduulf (talk) 17:29, 14 June 2016 (UTC)
- Why is the instruction related only to the WMF? --Izno (talk) 11:46, 14 June 2016 (UTC)
@Jura Your query, in a simpler form, returns <https://vec.wikipedia.org/>
instead of <https://vec.wikipedia.org>
like my query does, just because of the usage of schema:isPartOf. So (1) this doesn't mean that the behaviour of schema:isPartOf is a rule for what we should use in P856 for WMF sites and (2) more generally this doesn't mean at all that we need trailing slash for P856. So IMO this edit is also wrong. --Rotpunkt (talk) 15:23, 15 June 2016 (UTC)
- What's the disadvantage of adding the trailing slash to P856 for WMF sites? Why would it be an advantage of adding a new property instead?
--- Jura 15:36, 15 June 2016 (UTC)
- @Jura New property? Which new property? Regarding the trailing slash you can't reason about "disadvantage of adding", the URL (without subresources, like http://www.example.com/resource/ ) are *without* a trailing slash. And I don't find any W3C recommendations about adding it. The URL for enwiki, Google, Facebook, are
http(s)://en.wikipedia.org http(s)://www.google.com http(s)://www.facebook.com
, NOT:http(s)://en.wikipedia.org/ http(s)://www.google.com/ http(s)://www.facebook.com/
. --Rotpunkt (talk) 15:51, 15 June 2016 (UTC)- This is not about Google or Facebook. It's merely about WMF sites. We can't link it efficiently in query results without. Obviously, we could create a new property just for this purpose or modify WQS configuration, but I don't see an advantage of doing either if we end up with the same as we do now.
--- Jura 16:02, 15 June 2016 (UTC)- You can't link it efficiently in query results without that trailing slash? This is a problem of your query, it can't influence the value of P856. Show me your problem, and rollback this edit, please. --Rotpunkt (talk) 16:08, 15 June 2016 (UTC)
- Did you look at the 2nd sample query I provided? It lacks the item for vecwiki.
--- Jura 16:12, 15 June 2016 (UTC)- Now I will check, however you have to be a lot clearer in your explanations (especially for such important properties like this one). Only after several hours we have finally understood you have added this normalization for making a query work. --Rotpunkt (talk) 16:21, 15 June 2016 (UTC)
- @Jura With this query you get all six items without using P856 at all, but using P424 instead. Try also with items other then Q19610561, it is fast. Furthermore it can be semplified removing string functions (I didn't know if it's possible to get the language directly from the sitelinks). --Rotpunkt (talk) 20:10, 15 June 2016 (UTC)
- Not sure if this scales to 10000s of links. If you start out from other items (e.g. Leonardo da Vinci (Q762) ), one looses all non WP links. The existing solution doesn't have this issue.
--- Jura 05:04, 17 June 2016 (UTC)- @Jura Sure it works. About non-Wikipedia projects: replace ".wikipedia" with "." and you get items for all projects. Or use ".wikiquote", for example, if you want only wikiquote items. --Rotpunkt (talk) 09:29, 18 June 2016 (UTC)
- It seems to be confusing [2] Wikipedia with Wikisource and others. Let's stick to the working solution. One thing I don't quite get, what would be the benefit of using http or removing a "/" from WMF sites?
--- Jura 07:45, 22 June 2016 (UTC)- @Jura Because that slash is a workaround. It would be like: please use p:P558 in uppercase, only for pressure units, because it is needed for a query to work. I am discussing the problem with Smalyshev to see if there is a definitive solution (getting Wikimedia project item directly from the sitelink, without the need of any property at all). --Rotpunkt (talk) 09:18, 22 June 2016 (UTC)
- Hi guys, I think to make all this less of a waoraround, I think we may ask the devteam to add metadatas about wikimedia projects in the rdf datadump. There is already
schema:isPartOf <https://en.wikipedia.org> ;
on sitelink metadata, how can we further classify the wikimedia projects ? @Lea Lacroix (WMDE): is it possible to either add informations about the project and/or adding the wikidata item about that project ? Then we could use wikidata to add metadata about wikimedia and use those informations to filter the sitelinks. author TomT0m / talk page 10:14, 22 June 2016 (UTC)- Actually nevermind, it's already possible to join with official website (P856) ... I wonder ho efficient that is. author TomT0m / talk page 12:13, 22 June 2016 (UTC)
- It seems to be confusing [2] Wikipedia with Wikisource and others. Let's stick to the working solution. One thing I don't quite get, what would be the benefit of using http or removing a "/" from WMF sites?
- @Jura Sure it works. About non-Wikipedia projects: replace ".wikipedia" with "." and you get items for all projects. Or use ".wikiquote", for example, if you want only wikiquote items. --Rotpunkt (talk) 09:29, 18 June 2016 (UTC)
- Not sure if this scales to 10000s of links. If you start out from other items (e.g. Leonardo da Vinci (Q762) ), one looses all non WP links. The existing solution doesn't have this issue.
- @Jura With this query you get all six items without using P856 at all, but using P424 instead. Try also with items other then Q19610561, it is fast. Furthermore it can be semplified removing string functions (I didn't know if it's possible to get the language directly from the sitelinks). --Rotpunkt (talk) 20:10, 15 June 2016 (UTC)
- Now I will check, however you have to be a lot clearer in your explanations (especially for such important properties like this one). Only after several hours we have finally understood you have added this normalization for making a query work. --Rotpunkt (talk) 16:21, 15 June 2016 (UTC)
- Did you look at the 2nd sample query I provided? It lacks the item for vecwiki.
- You can't link it efficiently in query results without that trailing slash? This is a problem of your query, it can't influence the value of P856. Show me your problem, and rollback this edit, please. --Rotpunkt (talk) 16:08, 15 June 2016 (UTC)
- This is not about Google or Facebook. It's merely about WMF sites. We can't link it efficiently in query results without. Obviously, we could create a new property just for this purpose or modify WQS configuration, but I don't see an advantage of doing either if we end up with the same as we do now.
Archive of official site
[edit]See [3]. I suppose P856 cannot be directly used for this and we need either some qualifier or a new property? --Infovarius (talk) 10:03, 25 December 2016 (UTC)
Importing URLs from GRID
[edit]I am going to import official webpage URLs from the GRID dataset. I will use GRID ID (P2427) to match entries of the dataset with items. The statements will have a reference, which will be the DOI of the dataset they come from. Let me know if you have any concerns. − Pintoch (talk) 21:02, 1 February 2017 (UTC)
FTP
[edit]Are FTP sites like in [4] okay? --Pasleim (talk) 15:57, 9 February 2017 (UTC)
Property in Infoboxes
[edit]On the current discovery of seven exoplanets, I encountered the article TRAPPIST (English Wikipedia). The Infobox already uses data imported from Wikidata. The problem is that the Website category looks terrible and doesn't work. In Wikidata there are two equivalent websites stated (one in French, the other in English) and it doesn't fit the Infobox. In Wikipedia it is read as a single website. Is there any way to prettify it (maybe hide the link under a name) and is really necessary to have both websites? In the last case, if not, which website should stay? - Sarilho1 (talk) 12:11, 25 February 2017 (UTC)
Double http(s):// problem on zhwiki
[edit]cf. zh:Wikipedia:互助客栈/技术#.7B.7Binfobox_company.7D.7D.E6.8F.90.E5.8F.96.E7.BB.B4.E5.9F.BA.E6.95.B0.E6.8D.AE.E7.9A.84.E5.AE.98.E7.BD.91Property.E6.A0.BC.E5.BC.8F.E4.B8.8D.E5.AF.B9. --Liuxinyu970226 (talk) 12:43, 26 May 2017 (UTC)
what should be done with dead links?
[edit]- qualified with end date (or similar)?
- deprecated?
- removed?
d1g (talk) 13:44, 12 August 2017 (UTC)
- I guess "end date" with at least somevalue. But I guess that is only valid if the entity itself still exists. I mean, if a company is closed and the official website is closed as a consequence of that, the official website has been a valid site until the bitter end. An end date in such cases do not look like a good idea.
- I think it would be a good idea to add a "badge" to the url-datatype, making it an option to describe it as dead. -- Innocent bystander (talk) 07:09, 13 August 2017 (UTC)
- ...on second thought end date qualifier is the only option when company is active (no end time on item) d1g (talk) 12:06, 13 August 2017 (UTC)
- I think someone once set some of them to deprecated and added a qualifier (there was some discussion on Project Chat). Maybe one of the Internet Archive-bots could start adding archive URL (P1065) as qualifier.
In any case, I don't think they should be removed or replaced.
--- Jura 12:15, 13 August 2017 (UTC)
- Would it be possible to have a bot checking each month the status of each site, verifying the HTTP status codes and write that status? --Hannolans (talk) 09:13, 20 March 2019 (UTC)
- I advocate for qualifier "end date" with normal rank. Deprecated rank is for wrong data (never was correct), if there are some historical data and actual data, actual data can (should?) have preferred rank while historical should stay normal. --Infovarius (talk) 12:54, 21 March 2019 (UTC)
Constraint disallowing Internet archive URLs
[edit]Archive URLs cannot be used as an official website. They can only be used as a qualifier to the original website. We require a constraint that disallows archive URLs (string starting with http[s]://web.archive.org... as a value. John Samuel 10:28, 9 September 2017 (UTC)
Sounds reasonable.They can be added with the "archive URL" qualifier instead.
--- Jura 11:15, 9 September 2017 (UTC)- Instead of a constraint and to simplify imports, maybe a @Pasleim: could set up a Delta bot job that converts them to normal P856, a qualifier archive URL (P1065) and some indicator that it's no longer an active website.
--- Jura 11:21, 9 September 2017 (UTC)
- Done --- Jura 21:30, 4 July 2019 (UTC)
URL for publication
[edit]If a publication is available online (officially, from the publisher), should we use this property, or is there a better one? E.g. General History of Africa - Volume IV - Africa from the Twelfth to the Sixteenth Century (Q31369125). Bovlb (talk) 19:01, 14 March 2018 (UTC)
unique?
[edit]Sorry, I'm very much a Wikidata neophyte... did someone make a change to this property recently that makes it complain if another element has the same value for P856? Specifically I'm thinking of television programs where the main article would have, say, an official website of "https://blergh" and then you might want to use that same value as the official website for that program's season/series articles. So basically if I list "https://www.hbo.com/westworld" as the value for P856 for w:Westworld (TV series), it is throwing a warning/error if that same website is listed as the official website for w:Westworld (season 2) (as I did here). Or has this always been how this property is set up? I would think there could be multiple cases where an element might share an official website with another element, so this restriction seems like a bad idea. —Joeyconnick (talk) 21:31, 17 April 2018 (UTC)
- Actually, this property has been always set up like this. The newish thing is that you can see the "complaint" directly on the item. Matěj Suchánek (talk) 14:47, 18 April 2018 (UTC)
- I think the single value constraint is not much use for this property at all. I work on cinemas a lot, and often, there is one website for a cinema chain that is the best place to give as P856 also for the single local cinemas, since there is no proper landing point at the target website for that (but some Javascript navagation or the likes). Still, it's very helpful to have that Website at the respective cinema items. --Anvilaquarius (talk) 12:18, 20 April 2018 (UTC)
- I think the report shows quite a lot of non-unique sites that shouldn't be there, notably the same for two different politicians.
--- Jura 12:03, 21 April 2018 (UTC)
- Is there anyone in favor of this? Else I'll go ahead and remove it. I also don't think it makes a lot of sense. --dingensfünf 17:48, 8 February 2019 (UTC)
- I am much in favor of having this removed! I am modelling Greenland (Q223) and there are some very small municipalities such as Kujalleq (Q478813) that have small villages such as Aappilattoq (Q59117) and guess what? They have the same home page [5]. So there is no way for me to remove the non-unique flag... I would be much in favor of removing the single value constraint. --WiseWoman (talk) 08:26, 11 July 2023 (UTC)
Onion links
[edit]Many sites have official websites as wel as onion (Tor) links. This property only allows one, however. How can we proceed in such cases? I think I have proposed a specific property for these sorts of URLs, but it was not done and people suggested we use official website (P856) instead. NMaia (talk) 12:34, 22 April 2018 (UTC)
incorrect removal of YouTube URLs
[edit]Hi... there are several en.wikipedia.org pages for YouTube Red Original TV series where the articles' "official website" is a YouTube channel, yet this property is set up to automatically remove those and convert them to P2397. See, for example, en:Impulse (TV series), en:Cobra Kai, etc. This auto-conversion is creating errors in these cases, like here. Can we get it switched off or narrowed or something? —Joeyconnick (talk) 04:51, 15 May 2018 (UTC)
- It's still present as youtube channel. We don't add random twitter accounts or youtube channels. Besides, there are many other possible statements on Q48816788 that are missing. P856 isn't really essential.
--- Jura 08:25, 15 May 2018 (UTC)
Danish label and description
[edit]@Malore: Why was the Danish label and description changed? [6] [7]. To me it seems that that old label and description was better. — Finn Årup Nielsen (fnielsen) (talk) 19:06, 3 December 2018 (UTC)
- @Fnielsen: I changed as many labels and description as possible to reflect the result of [discussion]--Malore (talk) 19:24, 3 December 2018 (UTC)
- @Malore, Marsupium, JakobVoss : Reading Wikidata:Project chat/Archive/2018/11, I do not see there is any consensus on changing the Danish label. It is unclear if the semantics of the property has been changed, and if I should start using this property in another way that I usually do. — Finn Årup Nielsen (fnielsen) (talk) 19:39, 3 December 2018 (UTC)
- @Fnielsen: I don't know Danish. I copied the Danish translation of "homepage" from home page (Q11439), whose Danish label is "startside". Is home page (Q11439) wrong and "hjemmeside" is the correct translation?--Malore (talk) 21:05, 3 December 2018 (UTC)
- @Malore: Good question. I know read w:da:Startside. It is explained as what in the English Wikipedia article is called "browser home page". Searching https://ordnet.dk/korpusdk/, this sense seems to be the prevalent, though it can also be used to what I usually think of as (top-level) hjemmeside. — Finn Årup Nielsen (fnielsen) (talk) 22:48, 3 December 2018 (UTC)
- @Fnielsen: I don't know Danish. I copied the Danish translation of "homepage" from home page (Q11439), whose Danish label is "startside". Is home page (Q11439) wrong and "hjemmeside" is the correct translation?--Malore (talk) 21:05, 3 December 2018 (UTC)
- @Malore, Marsupium, JakobVoss : Reading Wikidata:Project chat/Archive/2018/11, I do not see there is any consensus on changing the Danish label. It is unclear if the semantics of the property has been changed, and if I should start using this property in another way that I usually do. — Finn Årup Nielsen (fnielsen) (talk) 19:39, 3 December 2018 (UTC)
Conflicting with date
[edit]Considering that the first website went live on August 6, 1991, would it be worth it to add a constraint saying an organization shouldn't have this property if it was dissolved before this date? HapHaxion (talk / contribs) 08:16, 11 May 2019 (UTC)
Distinct value ?
[edit]@Eurohunter: you added a distinct value contraint, I’m not sure it’s really appopriate. For example one alias of the property in english is « homepage » that do not suggests the « officiality ». My feeling is that this property has been used to link different things, not only the item of an institution, to a website. In that concern there is no reason that several items may not have the same « homepage ». (it did not took long for someone to add exceptions, see VIGNERON for example).
I have used it, for example, to link an official website item to its homepage. author TomT0m / talk page 07:41, 6 August 2019 (UTC)
- @TomT0m: Could you show example? Eurohunter (talk) 19:52, 6 August 2019 (UTC)
- There is for example items for which there is an item and an official website item. I found China for example : People's Republic of China (Q148) and Portal Website of the State Council, the People's Republic of China (Q10871931). And it seems generally that official website (P856) is used a lot on websites items. (this is related but we probably miss a property to link a website-item like corporate-website-item to its organisation-item, for example)
- It also seems to be pretty common to use the same url for different kind of awards, if they are distributed by the same organisation : see this query. author TomT0m / talk page 08:15, 7 August 2019 (UTC)
Miss Sudamerica Qualifier?
[edit]Why is Miss Sudamérica listed as a qualifier on official website? That must be a mistake --FeldBum (talk) 03:11, 3 September 2020 (UTC)
Fun fact
[edit]I might be wrong but it seems that the number 856 for this property perfectly matches the field number used in MARC standards (Q722609) to store the URL of a document : https://www.loc.gov/marc/bibliographic/bd856.html . Looking at the various discussions it does not seem to be done on purpose, did I miss something or it this totally random? Symac (talk) 17:28, 9 November 2020 (UTC)
- I am sure that it was a random occurrence. UWashPrincipalCataloger (talk) 00:46, 7 January 2021 (UTC)
forwards you to a domain seller
[edit]URL for official site forwards you to a domain seller. It is no longer valid. Keithistre (talk) 18:23, 6 January 2021 (UTC)
Where do we need dead websites?
[edit]Many of removed websites redirects to some domain selling site or some scam sites. Do we really need to store these on Wikidata? I have recently just removed all such websites that doesn't work anymore. What do you think, do we need those here? Stryn (talk) 13:48, 29 January 2021 (UTC)
- Set their rank to deprecated and add the qualifier reason for deprecated rank (P2241)link rot (Q1193907). The old URLs allow you to look up the website on the Wayback Machine and other website archives. —Dexxor (talk) 08:55, 30 January 2021 (UTC)
- Deprecation is actually incorrect. Normal rank is correct. Just set the end date to "unknown". There was some discussion if we should develop a feature that no longer makes the URLs link, but it was thought to be not worth the development. Ask at Wikidata:Contact the development team if you feel the question is worth re-visiting. --- Jura 09:01, 30 January 2021 (UTC)
- I have asked whether deprecation is correct (and a related question) at Wikidata:Project chat#Dead external links: normal or deprecated rank? (archived here), please comment. --colt_browning (talk) 17:12, 8 February 2022 (UTC)
- Wasn't Help:Ranking#Deprecated rank clear about this? --Horcrux (talk) 10:28, 11 May 2022 (UTC)
- I set P582 end time on Bitstream Inc., but French Wikipedia's Modèle:Infobox Société still displays a link on the Bitstream article. --Chealer (talk) 23:46, 14 January 2024 (UTC)
- @Chealer this is an frwiki issue, you can leave a message on fr:Projet:Modèle / fr:Projet:Infobox or similar page to signal that. author TomT0m / talk page 12:17, 15 January 2024 (UTC)
- Thanks, but this also affects the English Wikipedia's article. My point was that if setting an end date truly is the proper way to deal with these situations, then Wikidata's API probably has a design issue which needs each client to anticipate this scenario. I don't know Wikidata and Wikipedia/Mediawiki templates well enough to tell quickly, but editors likely shouldn't assume setting an end date to be sufficient to fix Infobox issues on Wikipedia. --Chealer (talk) 02:48, 17 January 2024 (UTC)
- @Chealer See Help:Ranking. In most cases if not specified explicitely, only the best rank statements are returned so it’s enough to make the value that is true nowdays appear. This allows to keep historical values for reference, or in that website case search the url in the archives for history of the website, for example. Some old page may be archived and of interest, for researchers for example. author TomT0m / talk page 17:24, 17 January 2024 (UTC)
- Thanks, that is a good thing if so. Unfortunately, "the value that is true nowdays" may not exist (it may be null, if you will). An entity does not necessarily have a website just because it used to have one. If we consider the example mentioned above, it would be unlikely that it gets a new website considering that it basically no longer exists. In any case, we should not rely on that happening to fix our info boxes. Chealer (talk) 18:33, 17 January 2024 (UTC)
- @Chealer There is a solution for that, I think I wrote something about that :
- create a statement with no value Help as preferred rank, with a begin date for which there is no website. With a begin date. There is a word about that in Help:evolving knowledge.
- author TomT0m / talk page 20:57, 17 January 2024 (UTC)
- Thanks, I did that with Bitstream Inc. and it improved things, but much still has to be done. The English version now reads "Website none", with a broken link on "none". As for French, that didn't help at all (result unchanged using Infobox Société). I wonder why both react differently, but I'm pretty confident that means none of these methods just makes the API ignore the dead website for default queries. Chealer (talk) 12:31, 18 January 2024 (UTC)
- @Chealer Both infoboxes are broken, imho. It’s easy to ignore corner cases when coding at first, especially when we don’t know which one are worth treating and which one virtually never happens. I’ll leave a word about that on the projects. author TomT0m / talk page 12:50, 18 January 2024 (UTC)
- I corrected at least the frwiki one. It now will not take into account statements with an end date and/or put a "there is no site now" message when there is a "no value" preferred statement. author TomT0m / talk page 18:50, 18 January 2024 (UTC)
- On enwiki the culprit is en:Template:Official URL which uses the enwiki en:Template:Wikidata which seem to provide in its advance usage a small language to select statements according to some criteria, this should be doable (but the template is fully protected, I left a message.) author TomT0m / talk page 19:09, 18 January 2024 (UTC)
- Thank you very much TomT0m. As Primefac mentioned in the discussion you started, he worked around the problem for that article. But thank you for reporting the (more?) fundamental problem. Chealer (talk) 13:14, 19 January 2024 (UTC)
- @Chealer Both infoboxes are broken, imho. It’s easy to ignore corner cases when coding at first, especially when we don’t know which one are worth treating and which one virtually never happens. I’ll leave a word about that on the projects. author TomT0m / talk page 12:50, 18 January 2024 (UTC)
- Thanks, I did that with Bitstream Inc. and it improved things, but much still has to be done. The English version now reads "Website none", with a broken link on "none". As for French, that didn't help at all (result unchanged using Infobox Société). I wonder why both react differently, but I'm pretty confident that means none of these methods just makes the API ignore the dead website for default queries. Chealer (talk) 12:31, 18 January 2024 (UTC)
- @Chealer There is a solution for that, I think I wrote something about that :
- Thanks, that is a good thing if so. Unfortunately, "the value that is true nowdays" may not exist (it may be null, if you will). An entity does not necessarily have a website just because it used to have one. If we consider the example mentioned above, it would be unlikely that it gets a new website considering that it basically no longer exists. In any case, we should not rely on that happening to fix our info boxes. Chealer (talk) 18:33, 17 January 2024 (UTC)
- Sorry, what's the problem with w:Bitstream? It even has no infobox. --Infovarius (talk) 11:23, 18 January 2024 (UTC)
- None. "bitstream" is a common noun, which is what the article you linked to treats. The problematic English article is the one about the company, Bitstream Inc. Chealer (talk) 12:35, 18 January 2024 (UTC)
- @Chealer See Help:Ranking. In most cases if not specified explicitely, only the best rank statements are returned so it’s enough to make the value that is true nowdays appear. This allows to keep historical values for reference, or in that website case search the url in the archives for history of the website, for example. Some old page may be archived and of interest, for researchers for example. author TomT0m / talk page 17:24, 17 January 2024 (UTC)
- Thanks, but this also affects the English Wikipedia's article. My point was that if setting an end date truly is the proper way to deal with these situations, then Wikidata's API probably has a design issue which needs each client to anticipate this scenario. I don't know Wikidata and Wikipedia/Mediawiki templates well enough to tell quickly, but editors likely shouldn't assume setting an end date to be sufficient to fix Infobox issues on Wikipedia. --Chealer (talk) 02:48, 17 January 2024 (UTC)
- @Chealer this is an frwiki issue, you can leave a message on fr:Projet:Modèle / fr:Projet:Infobox or similar page to signal that. author TomT0m / talk page 12:17, 15 January 2024 (UTC)
- I have asked whether deprecation is correct (and a related question) at Wikidata:Project chat#Dead external links: normal or deprecated rank? (archived here), please comment. --colt_browning (talk) 17:12, 8 February 2022 (UTC)
Rename property to website or home page
[edit]I am a bit puzzled why the name of the property is official website and not just website. It is not wrong, but the “official” prefix seems redundant. Other property names such as street address (P6375) or X username (P2002) are not prefixed with “official” – here it is implicit that the specified values are official.
The term “official website” is sometimes used about websites owned by celebrities, in contrast to websites operated by fans. This may have been more common in the early days of the internet, where many prominent people/organisations did not have their website. Such fan websites should obviously not be specified using official website (P856), but I don't think there is a high risk that people will add fan websites with this property, even if it is renamed.
The word official may be supposed to imply that this is a personal home page or the primary corporate website of an organisation, i.e. a website describing the person or organisation itself, contrary to other websites owned by the person/organisation. E.g. a company may have separate websites for different products and brands in addition to one website with pictures of the management, annual reports, and information about the history of the company. I assume it is the latter kind of website we want to capture with this property. Such websites are sometimes described as home pages or corporate websites. Strictly speaking, a website about a specific product made by a company is just as official as the company's corporate website.
I suggest renaming this property from official website to website or home page. --C960657 (talk) 10:32, 13 February 2021 (UTC)
- Probably a cultural thing. In some countries they seem to love the "official" part (whatever that may be), see also the next section. It's also a way of preventing all sorts of random (fan) links from being added. You might want to advertise this on the Wikidata:Project chat to get a bit more input. Multichill (talk) 17:43, 13 February 2021 (UTC)
Incorrect usage as reference
[edit]Some people have been incorrectly using this property for references instead of reference URL (P854). This now gives a constraint violation. Multichill (talk) 17:40, 13 February 2021 (UTC)
Qualifier addition
[edit]Please see Wikidata:Property proposal/url text about the qualifier to use when values that can't be entered on WMF websites. --- Jura 08:41, 1 April 2021 (UTC)
Distinct value constraint
[edit]This constraint does not seem to to particularly relate to the real world, where it is perfectly possible for one organisation to transfer its url to another. An real world example would be Oberelbische Verkehrsgesellschaft Pirna-Sebnitz, which was merged with other companies to form Regionalverkehr Sächsische Schweiz-Osterzgebirge. For some reason the latter has retained the former's url ( http://www.ovps.de/ ) as its principal url. I've tried getting rid of the resulting message by adding non-overlapping start and end date qualifiers to the property, but this seems to make no difference. -- Chris j wood (talk) 20:20, 25 July 2021 (UTC)
- "Constraints are hints, not firm restrictions" (Help:Property constraints portal). In most cases, the constraint is helpful at identifying duplicate items or wrong statements. —Dexxor (talk) 05:54, 26 July 2021 (UTC)
Wikidata property example
[edit]Currently a deleted page, "Mort Fertel", is the only example that shows an archived URL being used. It's not possible to see an example of the effect of the property with archive attributes ("archive URL (P1065)", etc.) on an active article now. Can someone replace that example with one where the article page was not deleted? Jamplevia (talk) 18:28, 10 February 2022 (UTC)
Added "writing system" as a property constraint
[edit]Since it is expected to add the language as a qualifier to the URL, it is necessary to specify the writing system used for languages which can be written using multiple systems. For example, Punjabi can be written using Gurmukhi or Shahmukhi script, and it would be inaccurate to say that the two scripts are different languages.--Middle river exports (talk) 16:48, 2 May 2022 (UTC)
Can applies to work be added as a valid qualifier?
[edit]Currently, applies to part (P518) is ok but applies to work (P10663) gives a flag. I'm asking for this addition in the context of video game characters having more than one official website for different games, publishers, regions, etc. Jotamide (talk) 12:09, 13 September 2023 (UTC)
Hijacked or dead websites
[edit]The current usage instructions instruct, "if the page changes, [to] add an additional statement with preferred rank [and] not [to] remove the former URL". Unfortunately, as can be seen in the "Where do we need dead websites?" section above, Wikidata's API visibly still exports the no longer valid websites by default, which requires clients to expect that. Even Wikipedia (even in English or French) doesn't know how to do this at this time.
In other words, if you follow the current instructions (leaving the former website) hoping to fix a Wikipedia article, you will likely fail, even if you follow the above section's advice (setting the end date to "unknown"). (Unless you have particular technical capabilities, probably including unusually high access.) Chealer (talk) 13:18, 12 February 2024 (UTC)
- Current description is much too long and should be trimmed. Multichill (talk) 18:16, 12 February 2024 (UTC)
- Why the description should link here? The relevant informations useful to a Wikidata reader/editor are in the section "Where do we need dead websites?" above. Maybe a new section "How to handle hijacked or dead websites" could be created and updated if necessary. -- ZandDev (talk) 21:22, 23 March 2024 (UTC)
Properties for academic websites
[edit]We are proposing some specific properties for types of academic websites, see this discussion Alessandro Marchetti (WMCH) (talk) 14:03, 27 July 2024 (UTC)
- All Properties
- Properties with url-datatype
- Properties used on 1000000+ items
- Properties with format constraints
- Properties with qualifiers constraints
- Properties with conflicts with constraints
- Properties with scope constraints
- Properties with single best value constraints
- Properties with constraints on items using them
- Properties with required qualifiers constraints
- Properties with entity type constraints
- Properties with unique value constraints
- Properties with complex constraints