Property talk:P813

From Wikidata
Jump to navigation Jump to search

Documentation

retrieved
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.
Associated item
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 valuesdate the information was retrieved (usually today's date) (note: this should be moved to the property 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
Example
According to this template: Source: stated in ->BNF: Date retrieved->June 7, 2013
According to statements in the property:
When possible, data should only be stored as statements
See alsopublication date (P577)
Lists
Proposal discussionProperty proposal/Archive/13#P813
Current uses24,938,817
[create] Create a translatable help page (preferably in English) for this property to be included here
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)
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: 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 (new)

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)

Symbol support vote.svg Support Almondega (talk) 13:34, 15 October 2015 (UTC)
Symbol support vote.svg 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)

Identifiers[edit]

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)