Property talk:P813

Documentation

• Start a query
• Current uses
• With precision and calendarmodel
• Statistics by class
• By century
• Calendar models
• List of qualifiers
• Count

retrieved
date or point in time that information was retrieved from a database or website (for use in online sources)

Description	date 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.
Represents	date retrieved (Q114946753)
Data type	Point in time
Template parameter	None. Template parameter: "accessdate" in citation templates (the "Cite xxx" series) at the English Wikipedia.
Domain	Part 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: 15 January 2001 ≤ 𝓧 ≤ 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 この属性の値は、協定世界時において、2001年1月15日（ウィキペディアが作成された日）から今日までの値であることを確認してください。
Example	Source: 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: usage	Category:Pages using Wikidata property P813 (Q98130865)
See also	publication date (P577), embargoed until (P11140)
Lists	Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Future dates Dates in Gregorian calendar before 1582 Dates before year 1 (Help:Dates#Years BC) Date on January 1 (Help:Dates#January 1 as date) Database reports/Constraint violations/P813 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 100,471,625 Main statement 49 <0.1% of uses Qualifier 118,401 0.1% of uses Reference 100,353,175 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 violations of this constraint: Database reports/Constraint violations/P813#Range, hourly updated report

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. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P813#Scope, SPARQL

Single value: this property generally contains a single value. (Help)

List of violations of this constraint: Database reports/Constraint violations/P813#Single value, hourly updated report, SPARQL

Allowed entity types are Wikibase item (Q29934200), Wikibase property (Q29934218), Wikibase lexeme (Q51885771), Wikibase form (Q54285143), Wikibase 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. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P813#Entity types

This property is being used by: fr:Modèle:Infobox Archidiocèse catholique/wd Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

Default value

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)

 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

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)

This is annoying warning, any progress? Ipr1 (talk) 23:19, 31 October 2021 (UTC)

I second that. Besides the warning message is unhelpful. Kpjas (talk) 23:15, 2 November 2021 (UTC)

Source constraint?

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)

Identifiers

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?

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

Such as wikipedia (with the oldid parameter):

 https://en.wikipedia.org/wiki/Lorem_ipsum?oldid=923463929

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)

How do I work this?

Should this be the latest retrieval? Or perhaps the first?

In my mind, this property should contain multiple values to establish the continuity of the specified data point. But I haven't given it much thought, and I'll gladly defer to the established guidance. Sadly I don't know where that lives.

I'm getting a little lightning bolt icon error telling me that "This property is generally expected to contain only a single value." Is that alert accurate? What are best practices for this property? What is the reasoning behind this being a single value argument?

Thanks for setting me straight :) Jerimee (talk) 03:46, 16 February 2024 (UTC)