Property talk:P1480

From Wikidata
Jump to: navigation, search

Documentation

sourcing circumstances
qualification of the accuracy of a statement: circa (Q5727902), near (Q21818619), presumably (Q18122778), disputed (Q18912752)
Description sourcing circumstances
Data type Item
Template parameter primary dates and places in infoboxes
Domain qualifiers can be used for references and also for claims, if all specified references for claim would have the same qualifier (note: this should be moved to the property statements)
Allowed values
According to this template:

limited set of values, precisely documented on property talk page, including:

According to statements in the property:
circa (Q5727902), presumably (Q18122778), possibly approximate value (Q21097017), unspecified calendar (Q18195782), unspecified calendar, assumed gregorian (Q26877139), unspecified calendar, assumed julian (Q26877143), specified date of both julian and gregorian calendar (Q27055388), misprint (Q21096955), miscalculation (Q21096985), disputed (Q18912752), misassociation (Q21097088), near (Q21818619), rarely (Q28962310), often (Q28962312), hypothesis (Q41719) and specified date of julian calendar (Q38173183)
When possible, data should only be stored as statements
Example
According to this template:

 

According to statements in the property:
gas lighting (Q856548)circa (Q5727902)
When possible, data should only be stored as statements
Source sources themselves, sometimes infoboxes for import ("born about 1234 year") (note: this information should be moved to a property statement; use property source website for the property (P1896))
Robot and gadget jobs some conditions shall be checked using bot:
See also stated as (P1932), refine date (P4241), earliest date (P1319), latest date (P1326)
Lists
Proposal discussion Property proposal/Archive/25#P1480
Current uses 28,447
[create] Create a translatable help page (preferably in English) for this property to be included here
One of circa (Q5727902), presumably (Q18122778), possibly approximate value (Q21097017), unspecified calendar (Q18195782), unspecified calendar, assumed gregorian (Q26877139), unspecified calendar, assumed julian (Q26877143), specified date of both julian and gregorian calendar (Q27055388), misprint (Q21096955), miscalculation (Q21096985), disputed (Q18912752), misassociation (Q21097088), near (Q21818619), rarely (Q28962310), often (Q28962312), hypothesis (Q41719), specified date of julian calendar (Q38173183): value must be one of the specified items. Please expand list if needed.
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P1480#One of, values statistics, SPARQL
Qualifier: this property can only be used as a qualifier.
List of this constraint violations: Database reports/Constraint violations/P1480#Qualifier, hourly updated report, SPARQL
Pictogram voting comment.svg No source
Statements with sourcing circumstances without reference
Violations query: SELECT DISTINCT ?item { ?st pq:P1480 [] . MINUS { ?st prov:wasDerivedFrom [] } . ?item ?p ?st } LIMIT 2500
List of this constraint violations: Database reports/Complex constraint violations/P1480
This property is being used by:

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

New value[edit]

After discussion here: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Creative_work#disputed_author , I created a new item here: disputed (Q18912752) . Can I add this new item to the list of possible values?--Mischa004 (talk) 10:27, 27 January 2015 (UTC)

This would also need to be changed:
Template parameter primary dates and places in infoboxes
--Mischa004 (talk) 10:31, 27 January 2015 (UTC)
Just do it. If there is a serious issue with it the discussion will come up someday, when there is a better or nicer solution.--Giftzwerg 88 (talk) 14:39, 11 February 2015 (UTC)

attributed to (P1773) and possible creator (P1779)[edit]

are two explicit properties expressing uncertainity of authorship with little (2*qualifier, 1*"primary" property) or no apparent usage at all yet). Shouldn't those two not better also be expressed by dedicated values for sourcing circumstances (P1480)? -- Gymel (talk) 22:43, 19 April 2015 (UTC)

And there are purported (de: angeblich) and presumed (de: mutmaßlich) authorships which IMHO are neither reflected here nor by P1773/P1779. And those cases of assumed authorship where it's today beyond any dispute that it can't be true but almost nothing about the possible true creator is known, cf. en:Pseudepigrapha#Authorship and pseudepigraphy: levels of authenticity which describes seven levels or de:Pseudepigraphie#Formen von Pseudepigraphie giving a classification based on the assumption of authorship being performed by the real author/third parties x intentionally/inadvertently. -- Gymel (talk) 23:11, 19 April 2015 (UTC)

And date ?[edit]

What about a use of this property and value circa (Q5727902) as qualifier for properties whose type is date : date of birth (P569), date of death (P570) , ... ?

It is shown in examples, but not compatible with constraint : {{Constraint:Source}} --Odejea (talk) 11:48, 6 December 2015 (UTC)

Indeed, it is used as a qualifier too. So that constraint should be removed in my opinion. Mbch331 (talk) 08:29, 14 December 2015 (UTC)
Yes, I agree that the constraint should be removed. Surely this is a necessary and correct use of circa.--Sic19 (talk) 17:05, 14 December 2015 (UTC)
Checked the history. It was added without discussion, so it can be removed without discussion too. Mbch331 (talk) 19:25, 14 December 2015 (UTC)

Ambiguous meaning[edit]

There are two different documented meanings:

  1. when used with "circa", "likely" etc., it's just a qualifier changing the exact meaning of the main value. It should be based on what a source says, but just like any other non-obvious statement. The label "sourcing circumstances" does not seem to make much sense in this case.
  1. when used with values like "miscalculation" or "misprint", that meaning is profoundly different. The qualifier does not report what the source says, but why we think the source is wrong. In this case, it is synonymous with reason for deprecation (P2241)

I would suggest to drop meaning 2) as reason for deprecation (P2241) does that unambiguously, and change the label to something more descriptive, like "value accuracy". --Zolo (talk) 11:35, 24 March 2016 (UTC)

I suppose that a label like "quality of data" would be closer to reality. --FocalPoint (talk) 17:39, 16 July 2016 (UTC)

I agree to that proposal. -Ash Crow (talk) 16:47, 2 October 2016 (UTC)
Thanks, I have changed the label to "quality of data" (waiting for complaints now...). --Zolo (talk) 11:44, 24 December 2016 (UTC)
@Zolo: :-))) I disagree with the changes that have been made, and have returned to the previous labelling. 'Qualify' and 'quality' mean different things and come from different latin roots. Qualifying with "circa", ie. died c. 25 September 1884 indicates uncertainty of exactness, which, is different from the quality of the date (noting that dates cannot have "quality"). So you might be talking about the quality of the source, but the source could be excellent, however, it cannot get around uncertainty. So this needs a rethink. If you are wanting "quality of data", then we are going to need to split out "circa" dates to a different qualifier.  — billinghurst sDrewth 12:54, 25 December 2016 (UTC)
"qualification of data" would work for "circa"  — billinghurst sDrewth 13:01, 25 December 2016 (UTC)
@FocalPoint, Ash Crow:. Addendum. Is this a case of trying to achieve a number of close circumstances with the one property. We are talking about uncertainty of source, versus uncertainty of knowledge, which are different things.  — billinghurst sDrewth 12:58, 25 December 2016 (UTC)

Hi billinghurst. It is clear now. I do not care for title, but the description for the two properties needs to be something like:

  • uncertainty of source (the source is believed to be wrong)
  • uncertainty of knowledge (the source is accepted as correct, but the source indicates an uncertain value)

Please confirm that I understood correctly. --FocalPoint (talk) 13:45, 25 December 2016 (UTC)

Those are the two that I see. Maybe other cases. Now whether they are one or two properties is open for debate. (I could comment more but it is probably "blah blah blah".)  — billinghurst sDrewth 14:08, 25 December 2016 (UTC)
In practice, "uncertainty of knowledge" is what the property is about. Statistics are here: http://tinyurl.com/jorl7u7 . Since uncertainy of knowledge has no direct connection to sourcing, any label will be at least as good as "sourcing circumstances".
If the truthfullness of what a source states is disputed, you can show that with statement disputed by (P1310). If it is known to be wrong, you can use the deprecated rank + minimum date (property constraint) (P2310).
I have no strong opinion about the label. "qualification of data" is probably better than "quality of data", but I don't think "quality of data" is wrong (poor quality of the data means that the facts are not well known, not that the source makes a bad job relative to what is achievable). --Zolo (talk) 16:10, 25 December 2016 (UTC)
A later thought, the qualifier used should be able to distinguish the type of uncertainty and that may allow one label, and allow the type of qualifier to differentiate.
@Zolo: Why I was against the "quality of data", the example that I gave came from a report of death of a journalist in Sudan who was captured, and it may have been the 25th that he was killed, or the 26th. the executors didn't say. The data of capture is known, and the date of the discovery of the bodies are unknown, and there is a tight range, but not exact knowledge. Quality of data is excellent, there is just uncertainty +/- a day.  — billinghurst sDrewth 06:08, 28 December 2016 (UTC)

Challenge use of "presumably" to qualify a year of birth or death[edit]

I do not find the use of "presumably" to qualify a date of birth/death as that helpful, and hard to manage and qualify in infobox usage. It is not a common practice with the use of "circa", the more expected practice (my opinion). I can see that we can use presumed for some dates where it is within a series of events of known dates, however stepping outside the usual use of circa, seems unusual, especially in our guidance.  — billinghurst sDrewth 01:10, 4 February 2017 (UTC)

Propose new qualifying item "believed"[edit]

I have the source s:Reading, John (d.1692) (DNB00) where it states that John Reading (Q6254393) is 'believed" to be buried in a place. The allowed qualifiers do not meet this circumstance. Obviously it would need to be referenced if used.  — billinghurst sDrewth 10:50, 6 May 2017 (UTC)

@Mbch331, Zolo: prior to my editing ... ^^  — billinghurst sDrewth 16:49, 19 May 2017 (UTC)
@billinghurst: Not really against it, but I then the description of presumably (Q18122778) should be improved to make the distinction clearer. --Zolo (talk) 13:14, 23 May 2017 (UTC)

Before and after[edit]

In the particular context of birth and death dates, is it worth allowing "before" and "after" as valid qualifiers? We get quite a lot of these for historic figures - particularly "after", when they disappear from the record entirely. We can use unknown, of course - not sure which way is better. Andrew Gray (talk) 13:04, 18 June 2017 (UTC)

Isn't that the function of floruit (P1317) to state what is known? Sure it means that we have to presume the other, however, too often I have seen BEFORE/AFTER dates become take as actual dates. I also find them somewhat corrupting when they are used based on a person's individual knowledge.  — billinghurst sDrewth 16:52, 18 June 2017 (UTC)