Property talk:P813

From Wikidata
Jump to navigation Jump to search


date or point in time that information was retrieved from a database or website (for use in online sources)
Descriptiondate that information was retrieved from a database or website. Use as additional qualifier when adding online sources.
To do this you need to create the link to the website or online database and save it. Then you go back and edit it and you will see a link to "Add" more source claims. Add 'date retrieved' and the date the information was retrieved from the online source.
Data typePoint in time
Template parameterNone. Template parameter: "accessdate" in citation templates (the "Cite xxx" series) at the English Wikipedia.
DomainPart of statement references. Not to be used in claims or qualifiers. (note: this should be moved to the property statements)
Allowed values
According to this template: date the information was retrieved (usually today's date)
According to statements in the property:
≤ 𝓧 ≤ unknown
When possible, data should only be stored as statements
Usage notes確認該屬性的值位於2001年1月15日(維基百科成立日期)至今天之間
Vénfiez que la valeur de cet attribut se situe entre le 15 janvier 2001 (date de création de Wikipedia) et aujourd'hui
Certifique-se de que o valor deste atributo se situa entre 15 de Janeiro de 2001 (data da criação da Wikipédia) e hoje
ExampleSource: stated in ->BNF: Date retrieved->June 7, 2013 (note: this information should be moved to a property statement; use property Wikidata property example (P1855), Wikidata property example for properties (P2271), Wikidata property example for lexemes (P5192), Wikidata property example for forms (P5193) or Wikidata property example for senses (P5977))
Tracking: usageCategory:Pages using Wikidata property P813 (Q98130865)
See alsopublication date (P577)
Proposal discussionProposal discussion
Current uses
Main statement38<0.1% of uses
Qualifier45,338<0.1% of uses
Reference75,822,410>99.9% of uses
[create Create a translatable help page (preferably in English) for this property to be included here]
Range from “+2001-01-15T00:00:00Z” to “now”: values should be in the range from “+2001-01-15T00:00:00Z” to “now”. (Help)
List of this constraint violations: Database reports/Constraint violations/P813#Range, hourly updated report, SPARQL (new)
Scope is as reference (Q54828450), as qualifier (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/P813#scope, SPARQL, SPARQL (new)
Single value: this property generally contains a single value. (Help)
List of this constraint violations: Database reports/Constraint violations/P813#Single value, hourly updated report, SPARQL, SPARQL (new)
Allowed entity types are Wikibase item (Q29934200), Wikibase property (Q29934218), lexeme (Q51885771), form (Q54285143), sense (Q54285715), Wikibase MediaInfo (Q59712033): the property may only be used on a certain entity type (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P813#allowed entity types, SPARQL (new)
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Default value[edit]

Can we provide the default value for this property? It would be very convenient, if one adds this property to a reference, to automatically set the text in the value text field to current date. I do not know whether we have technical ability to do so, maybe using JS? Nonexyst (talk) 16:55, 31 August 2015 (UTC)

 Support Almondega (talk) 13:34, 15 October 2015 (UTC)
 Support Carlos Porto (talk) 23:12, 15 October 2015 (UTC)
Pictogram voting comment.svg Comment Have a look at User_talk:TMg/currentDate.js -- it's a script which automatically sets the retrieved (P813) claim to the current date. Pixeldomain (talk) 02:40, 8 August 2016 (UTC)

Current date and Time zones[edit]

How about the difference in time zones versus the constraint when using the current date script when you are manually correcting to local offcial timezone date ? Best regards Migrant (talk) 23:14, 1 April 2018 (UTC)

Currently this constraint seems to warn (annoying!) when editor includes current date ("retrieved") e.g. for some URL / data source after checking that and edits this after midnight (in Central/Eastern Europe). Then, date in USA has not yet reached the same date. --Paju~wikidatawiki (talk) 22:54, 3 April 2018 (UTC) (this username is for wikidata)
Indeed; this ought to be fixed. I edit in UTC+12 (+13 during summer) and anything that I edit before lunchtime (1pm in summer) comes up with the date error. Schwede66 (talk) 23:40, 25 June 2018 (UTC)
This bug is still bothering us, needs to be fixed. If editing after midnight, and inserting current date (retrieved), just those editors with local time in range UTC...UTC+12 (?) are accepted without warning. So, I guess, half editors of the World (populationwise more) are warned, including small countries like India and China... How about editors from Australia and New Zealand, are you experiencing the same bug? Editing mostly with computer using time zone of Helsinki, Finland, last night I was warned till 3 a.m. after which editing went without warning... (local date changes 3 hours prior UTC zone). There is Wikipedia Asian Month coming in just few days (November). Please consider fixing this prior to that! --Paju~wikidatawiki (talk) 08:30, 26 October 2018 (UTC)

Source constraint?[edit]

According to the current source constraint on this property, it shall only be used within sources. This appears to be too strict, since for instance official website (P856) requires and equivalent class (P1709) frequently uses retrieved (P813) as a qualifier. That actually makes sense to my opinion. Could we find a better constraint condition than the present source constraint? (See also: Wikidata:Database reports/Constraint violations/P813#"Source" violations, which lists some other affected properties as well). What to do? —MisterSynergy (talk) 11:21, 24 October 2015 (UTC)

point in time (P585) seems more suitable for official website (P856). The dbpedia stuff is just incorrectly uploaded. --- Jura 11:26, 24 October 2015 (UTC)
I think retrieved (P813) was chosen for official website (P856) as a qualifier to reflect that its value is the time of checking this relation. point in time (P585) seems to be a poor alternative to me, I’d consider start time (P580) and end time (P582) more suitable. That would be an intrinsic property of the statement, rather than one arbitrary access date within such a time frame. However, it might be difficult to determine correct values for start time (P580) and end time (P582)…. So I still think it would be a feasible solution to permit a broader use of retrieved (P813) by removing/changing this constraint. —MisterSynergy (talk) 11:51, 24 October 2015 (UTC)
start time (P580) and end time (P582) is not suitable if the dates are not known. point in time (P585) just states when the statement is known to be correct.
There may be an advantage in having a dedicated property for "official website", but I don't think this should be done by polluting the definition of P813. --- Jura 12:03, 24 October 2015 (UTC)


Further to the previous section, I would like to use this property to record the last time an identifier was checked, and confirmed to be a working live link.

More broadly, it seems to me that this property (or alternatively a clone of it) would be desirable as a qualifier to any URL-valued property: so effectively anything on this list [1], in addition to identifiers that can be resolved to URLs. Jheald (talk) 01:52, 23 January 2017 (UTC)

Do I need the property, if my link is a permalink?[edit]

some websites provide a permalink function, that creates a stable of the current version of the content.

Such as wikipedia (with the oldid parameter):

Mediawiki then announces all the nessessary details in the page header:

This is an old revision of this page, as edited by [user] at 18:39, 28 October 2019 [commit message]. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In such cases the retrieved (P813) property is unnessary, isn't it? --Loominade (talk) 10:12, 7 November 2019 (UTC)