item is described at the following URL
|Domain||This is to be used to provide links to reliable external resources that are not the item's official website, when no relevant "authority control" property exists (note: this should be moved to the property statements)|
|Example||Mona Lisa (Q12418) → http://musee.louvre.fr/oal/joconde/indexFR.html|
Eleanor J. Gibson (Q299908) → http://www.feministvoices.com/eleanor-j-gibson/
Graphics Interchange Format (Q2192) → https://www.w3.org/Graphics/GIF/spec-gif89a.txt
Susan Grey Akers (Q56649770) → https://finding-aids.lib.unc.edu/04774/
|Tracking: usage||no label (Q61035506)|
|See also||external data available at (P1325), described by source (P1343), exact match (P2888), curriculum vitae URL (P8214)|
|Proposal discussion||Proposal discussion|
|Search for values|
|Scope is as main value (Q54828448), as qualifiers (Q54828449): the property must be used by specified way only (Help)|
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P973#scope, SPARQL, SPARQL (new)
|Required qualifier “language of work or name (P407)”: this property should be used with the listed qualifier. (Help)|
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P973#mandatory qualifier, SPARQL, SPARQL (new)
URL shorteners blacklisted on Commons, but allowed in Wikidata - causes a bug.Edit
The problem is that this URL shortener (
https://skfb.ly/66xYF) is allowed in Wikidata, but blacklisted in Commons where it is used loaded in the file description (via the Artwork template).
Even though I removed the link completely on the description of the image file, this URL was still in the "described at URL (P973)" property of the item, and so without changing anything, it was impossible to avoid the error occuring in Commons on its file description page while it was regenerated to display the link from Wikidata.
For this reason, I not only modified the description page on Commons (to remove the link), but also I had to replace the shortened link by the non-redirecting target URL (
https://sketchfab.com/3d-models/dupondius-doctave-a-la-tete-de-belier-48e52062e37d4a6194a36f76f6eb959f) in sketchlab.com used in the property on Wikidata.
With the blacklist on Commons, and without my edit on both wikis, the page on Commons would have had a permanent "Pages with scripting errors" (or everything in the description could not be modified (except by dropping the template loading URLs from wikidata).
Note that the URL set in Wikidata was used as a reference for the source and for asserting the CC0 licence, visible on the target site of the shortened URL.
- Is there a way for Wikidata to not allow blacklisted URLs (notably domains for URL shorteners)?
- What if Wikidata and Commons and other wiki editions allow some URLs, but another wiki blacklists it? This wiki will have problems to render pages trying to show URLs accepted in Wikidata but not the local wiki. I see no easy solution except modifying Wikidata (if we can replace the redirecting URL).
- Same question if a local wiki accepts an URL in its file descriptions, but not Wikidata or Commons: it's then impossible to import the file to Commons or set the property in Wikidata.
- Shouldn't the URL blacklists be synchronized across Wikimedia wikis (at least URL shorteners)?
- Can we set in Wikidata a qualifier on the P973 property value, saying that the URL is not accepted in some other wiki, so that templates on this wiki will discard the URL set by P973 ?
- Should we propose the qualifier "URL blacklisted on" to be used on URL properties, and whose qualifier value would be the Qid of the wiki rejecting such URL?
I think that Wikidata should also have a policy not allowing any shortened URLs in its URL properties, but only direct URLs (but this may be a problem for linking some sites, where the only stable URLs are actually always shortened with an identifier, while the target of the short URL can change at any time (e.g. some links to Microsoft site) and the effective target no longer worling or working only for the current session of the visitor and possibly containing a private authentication of the visitor.
An alternative would be that the URL allowed in Wikidata would have some OTRS qualifier, allowing the wiki displaying the link to bypass his local blacklist. Such OTRS qualifier, where it is used, would be checked by some bot to see if it really matches the Wikidata item added in the OTRS database for this URL.
Add "described at DOI"?Edit
KrBot was editing "described at URL" with a DOI value, moving it to "DOI". However "described at URL" is clearly not the same as "located at URL", and "DOI" property means "located at DOI". Should there be a property added, called "Described at DOI"? --Mcld (talk) 18:28, 22 August 2020 (UTC)
- If the DOI isn't about the item you are trying to add it to, you'd have to make an item about the resource it describes first and add it there. --- Jura 06:10, 23 August 2020 (UTC)
I don't quite see why we shouldn't use the dedicated property. Accordingly, I re-added it. --- Jura 05:46, 11 September 2020 (UTC)
- Discussion now at Wikidata:Project_chat#Items_for_specific_YouTube_video. --- Jura 16:03, 13 September 2020 (UTC)