Property talk:P1480

Documentation

sourcing circumstances
qualification of the truth or accuracy of a source: circa (Q5727902), near (Q21818619), presumably (Q18122778), etc.

Description

sourcing circumstances

Represents

sourcing circumstance (Q104637420)

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:

circa (Q5727902) -- the source specified value and explicitly stated that value is approximate, but specify no precision information. For example, "born around 1709" or "died near Berlin".
presumably (Q18122778) -- the source specified value and explicitly stated that value is presumed. For example, "presumably born in 1709" or "presumably died in Berlin".
possibly approximate value (Q21097017) -- the source specified not-ideally-precise value (like year instead of date of birth) and did not explicitly stated that value is approximate, but other sources explicitly did.
unspecified calendar (Q18195782), unspecified calendar, assumed Gregorian (Q26877139), unspecified calendar, cagada humana pd: julian (Q26877143) -- the source did not explicitly specify used calendar for dates between 1582-10-15 and 1918-01-26 (or, for example, for dates in context when Japanese calendar could be used), calendar model is assumed basing on source information and/or comparison with other sources
specified date of both Julian and Gregorian calendar (Q27055388)
misprint (Q21096955) -- the information in source differs very little from other sources and suspect to have a typo
miscalculation (Q21096985) -- source provides both calculation sources, methodology (or link to it) and calculation result, but result is different from other sources and manual calculation basing on provided description
near (Q21818619) -- for a place

According to statements in the property:
unspecified calendar (Q18195782), unspecified calendar, assumed Gregorian (Q26877139), unspecified calendar, cagada humana pd: julian (Q26877143), specified date of Gregorian calendar (Q51367591), specified date of both Julian and Gregorian calendar (Q27055388), statement with Gregorian date earlier than 1584 (Q26961029), specified year ab Urbe condita (Q106591773), specified date of Islamic calendar (Q106419137), conventional date (Q105769095), to be announced (Q603908), miscellaneous (Q2302426), hierarchical link is not direct (Q50095342), URL redirection (Q1236807), misprint (Q21096955), misassociation (Q21097088), misattribution (Q105675146), according to some sources (Q59783740), possibly (Q30230067), probably (Q56644435), allegedly (Q32188232), presumably (Q18122778), hypothetically (Q18603603), expected (Q50376823), undetermined (Q106160493), estimate (Q37113960), disputed (Q18912752), cancelled (Q30108381), classified (Q59608653), pending investigation (Q15729048), possibly approximate value (Q21097017), approximation (Q27058), approximately (Q60070514), circa (Q5727902), near (Q21818619), greater than (Q47035128), less than (Q52834024), greater than or equal to (Q55935291), less than or equal to (Q55935272), minimum (Q10585806), maximum (Q10578722), average (Q202785), less (Q84761689), more (Q54418095), mean (Q2796622), common (Q54836621), optional (Q59864995), inference (Q408386), convention (Q367293), attribution (Q230768), contradiction (Q363948), sic (Q192003), uncertainty (Q13649246), existence uncertain (Q86454040), posthumous (Q60503972), unpublished work (Q26944781), unofficial (Q29509080), dubious role (Q70650920), incorrect name in source (Q77066609), no diacritics in source (Q108172170), fragment (Q3749265), work in process (Q357662), upcoming song (Q67608251), upcoming single (Q65706647), upcoming album (Q59564754), upcoming music video (Q93376240), end of (Q40719766), before (Q79030196), after (Q79030284), text exceeds character limit (Q105642994), no earlier than (Q110290991), no later than (Q110290992), illegible (Q110558700), sp. (Q1423364), de facto (Q712144), uncitedness (Q2492572), approximate centre point (Q109104929), more veneto (Q1240711), missing data (Q6878417), unupdated (Q112980637), dubious (Q104378399), unspecified value (Q115464513), date of signature (Q100256464), incorrect grammatical gender in source (Q117712427), incorrect part of speech in source (Q119448805), on-site survey (Q120965429), statement with potentially incorrect Julian date (Q26932615), periodically (Q122426205), specified date of Julian calendar (Q38173183), almost equal to (Q123383098), sometimes (Q110143752), requested removal (Q123137336), mainly (Q91013007), unrecognized (Q125227227), intercalated (Q125227128) or derived from Google Maps (Q125850337)

When possible, data should only be stored as statements

Example

According to this template:

misprint (Q21096955) example
- Yevgeniy Yevstigneyev (Q1344765) → date of birth (P569)
  - 1926-10-09 ( rank = normal )
    - ( stated in Krugosvet (Q2627728) )
  - 1936-10-09 + ( rank = deprecated )
    - (as qualifier), sourcing circumstances (P1480) = misprint (Q21096955)
    - ( stated in Integrated Authority File (Q36578), sourcing circumstances (P1480) = misprint (Q21096955) )
circa (Q5727902) example
- Al-Khwarizmi (Q9038) → date of birth (P569)
  - 780 ( rank = normal )
    - (as qualifier) sourcing circumstances (P1480) = circa (Q5727902)
    - ( stated in Biographical Encyclopedia of Astronomers (Q14525437), sourcing circumstances (P1480) = circa (Q5727902) )
    - ( stated in MacTutor History of Mathematics archive (Q547473), sourcing circumstances (P1480) = circa (Q5727902) )
    - ( stated in Integrated Authority File (Q36578), sourcing circumstances (P1480) = possibly approximate value (Q21097017) )
  - 783 ( rank = normal )
    - (as qualifier) sourcing circumstances (P1480) = circa (Q5727902)
    - ( stated in Krugosvet (Q2627728), sourcing circumstances (P1480) = circa (Q5727902) )

According to statements in the property:
gas lighting (Q856548) → circa (Q5727902)
expansion of the universe (Q1129469) → hypothetically (Q18603603)
Air France Flight 447 (Q185380) → near (Q21818619)
Great Train Robbery (Q1140155) → approximately (Q60070514)
Tomb of the Unknown Soldier in Paris (Q523312) → presumably (Q18122778)
Taiwan (Q865) → disputed (Q18912752)
pi (Q167) → approximately (Q60070514)
doomsday (Q1036775) → allegedly (Q32188232)
suffrage in France (Q3039728) → varies by state/province (Q27145860)
Area 51 (Q177397) → according to some sources (Q59783740)
Xavier Jugelé (Q29533295) → posthumous (Q60503972)
Israel (Q801) → unofficial (Q29509080)
Dietrich of Apolda (Q108567) → statement with Gregorian date earlier than 1584 (Q26961029)
Battle of Marignano (Q330) → statement with Gregorian date earlier than 1584 (Q26961029)

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:

some values implies existence of other claims with sources and "deprecated" rank of the claim (misprint (Q21096955), miscalculation (Q21096985))
some values implies existence of other references to the same claim (possibly approximate value (Q21097017), unspecified calendar (Q18195782) (if attached to reference))
unspecified calendar (Q18195782) could be used only for time

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)[reply]

This would also need to be changed:

Template parameter primary dates and places in infoboxes

--Mischa004 (talk) 10:31, 27 January 2015 (UTC)[reply]

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)[reply]

P1773 (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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Checked the history. It was added without discussion, so it can be removed without discussion too. Mbch331 (talk) 19:25, 14 December 2015 (UTC)[reply]

Ambiguous meaning[edit]

There are two different documented meanings:

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.

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 deprecated rank (P2241)

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

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

I agree to that proposal. -Ash Crow (talk) 16:47, 2 October 2016 (UTC)[reply]

Thanks, I have changed the label to "quality of data" (waiting for complaints now...). --Zolo (talk) 11:44, 24 December 2016 (UTC)[reply]

@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)[reply]

"qualification of data" would work for "circa" — billinghurst sDrewth 13:01, 25 December 2016 (UTC)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@Zolo, Ash Crow, FocalPoint: we need to go back and tidy up this property as discussed, as you will see the discussion today is building on this ambiguity of "uncertainty of source" v. "uncertainty of knowledge". the longer we wait, the harder the cleanup. — billinghurst sDrewth 11:28, 7 February 2018 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Here are the most used values of this property (query) circa (Q5727902) (30037)
hypothetically (Q18603603) (2877)
presumably (Q18122778) (1975)
disputed (Q18912752) (573)
near (Q21818619) (423)
possibly (Q30230067) (407)
hypothesis (Q41719) (209)
unofficial (Q29509080) (63)
often (Q28962312) (44)
fiscal year (Q191891) (37)
uncertainty (Q13649246) (32)
presumably (Q35976085) (26)
doubt (Q34302) (21)
end of (Q40719766) (21)
misprint (Q21096955) (15)
de facto (Q712144) (11)
possibly approximate value (Q21097017) (11)
rarely (Q28962310) (10)
error (Q29485) (9)
official (Q29509043) (9)

Agree on a new label. "Qualification of data" is ok with me though I'd like something less wonky. The important point is that we remove the unwarranted reference to sourcing.
Clean up property usage (use reason for deprecated rank (P2241) for misprint (Q21096955)). In some cases, we may not really have anything that fits but some other qualifiers would be a bit better (like criterion used (P1013) for "fiscal year" or applies to part (P518) for the value used on Commons (Q38366566)). --Zolo (talk) 17:02, 8 February 2018 (UTC)[reply]

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)[reply]

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)[reply]

@Mbch331, Zolo: prior to my editing ... ^^ — billinghurst sDrewth 16:49, 19 May 2017 (UTC)[reply]

@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)[reply]

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)[reply]

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)[reply]

de facto, interim, acting[edit]

P794 (P794) is being deprecated and some of its uses with position held (P39) and country (P17) are being transferred to this qualifier. To accept those statements, I have added de facto (Q712144), interim (Q4895105) and acting (Q4676846) to the list of allowed values of this qualifier so we can use the property to represent statements like Raúl Savarese (Q21694119)position held (P39)Mayor of Buenos Aires (Q21693213)sourcing circumstances (P1480)interim (Q4895105). Deryck Chan (talk) 21:22, 4 November 2017 (UTC)[reply]

Please don't. This has just nothing todo with sourcing.
--- Jura 21:45, 4 November 2017 (UTC)[reply]
- @Jura1: I was following the proposals at this deletion discussion. I presume we got here because the proponents of this as a replacement for P794interim (Q4895105) etc did not distinguish between "circumstances accuracy of statement" and "circumstances and accuracy of sourcing". Please propose a better qualifier to accept these qualifiers and I'll port those qualifiers there instead. Deryck Chan (talk) 22:03, 4 November 2017 (UTC)[reply]

"Deryck Chan This property is for "qualification of the accuracy of a statement". For example a statement, like time or place, can be approximate circa (Q5727902), assumed based on other facts presumably (Q18122778), disputed by others disputed (Q18912752), etc. but it can not be acting (Q4676846) or interim (Q4895105). I think there should be a property for Raúl Savarese (Q21694119)position held (P39)Mayor of Buenos Aires (Q21693213)P????interim (Q4895105), but sourcing circumstances (P1480), is not it. If there is not any than you should propose one but you can not pick a random existing one and use that. --Jarekt (talk) 02:37, 5 November 2017 (UTC)[reply]

Concur with Jarekt's and Jura's opinions. The advice at the deletion discussion seems wrong. — billinghurst sDrewth 10:12, 5 November 2017 (UTC)[reply]

I agree. There is a need for his kind of qualifier, but P1480 isn't suitable. Perhaps subject has role (P2868)? Andrew Gray (talk) 10:43, 5 November 2017 (UTC)[reply]

subject has role (P2868) would be the next closest match, though we would still be polluting "roles" with "accuracy of statement". Until a better property gets invented, it would probably be best to dump all these qualifiers over there. Deryck Chan (talk) 17:01, 5 November 2017 (UTC)[reply]

The other "catch-all" property is significant event (P793); it's not really right, but it's sometimes good enough for this sort of "I have a special case and want to note it" qualifier. Andrew Gray (talk) 18:45, 5 November 2017 (UTC)[reply]

One could argue that the position held is "(acting|interim) mayor of Buenos Aires" and that should be a role on its own that is a subclass of "mayor of Buenos Aires" as what does interim mean anyway? They usually fulfil the role, and the interim is around the term, which we can specify, not around the powers. — billinghurst sDrewth 21:44, 5 November 2017 (UTC)[reply]

Just to clarify, I don't think I said or wrote this.
--- Jura 14:42, 18 November 2017 (UTC)[reply]

Okay. I've originally made those alias changes in preparation for adjusting the scope of this property to include things like "de facto". Deryck Chan (talk) 17:20, 8 December 2017 (UTC)[reply]

@Swpb, Pasleim, Jura1, billinghurst, Multichill: Swpb and Pasleim have widened the purpose of this property to cover both "accuracy of the sourcing" (e.g. this person is presumably born in 1876 [but we aren't quite sure]) and "accuracy of the underlying truth" (the sky is usually blue [but occasionally grey]). I personally think that's an appropriate direction to move towards but want to bring up this discussion again before, well, porting items in. Deryck Chan (talk) 21:22, 12 December 2017 (UTC)[reply]

Actually, I have rethought that. I think sourcing circumstances (P1480) might be best limited the accuracy or reliability of a statement, not other aspects of its status, since there are other properties that suit those purposes. (I've made a breakdown of all these qualifiers for my own edification, that might shed light on my thinking.) For "de facto"/"de jure", I've been using determination method (P459), which I've widened accordingly. For "interim"/"acting", subject has role (P2868) is workable. Either way though, I think existing properties can be made to fit the purposes; I don't see much value in a new property. Swpb (talk) 21:35, 12 December 2017 (UTC)[reply]

Comment Even with the changes made to the constraints I still do not see that "interim", "acting", etc. belong under sourcing circumstances. There is nothing relating to sourcing, it relates to the term and the method of the appointment. — billinghurst sDrewth 06:24, 13 December 2017 (UTC)[reply]
Comment This again seems unrelated. @Deryck Chan: Maybe you could explain your usecase and we can try to help you find the right properties/qualifiers. What data do you want to add?
--- Jura 08:16, 13 December 2017 (UTC)[reply]

We need to find somewhere to take these statements:

SELECT ?item ?itemLabel ?property ?propertyLabel ?value ?valueLabel ?asObject ?asObjectLabel
WHERE
{
    ?prop pq:P1480 ?asObject .
  	hint:Query hint:optimizer "None" .	
	?item ?p ?prop . 
	?property wikibase:claim ?p .  
  	?property wikibase:statementProperty ?ps .
    ?prop ?ps ?value .      
    wd:P39 wikibase:claim ?p
	SERVICE wikibase:label { bd:serviceParam wikibase:language "en"  }    
}
LIMIT 1000

Try it!

Also @Swpb, Jura1: Where did you port all those statements that used to say (person)award received (P166)(award)as"in memoriam"? --Deryck Chan (talk) 09:57, 13 December 2017 (UTC)[reply]

@Deryck Chan: The P794 (P794)=in memoriam (Q3509975) qualifiers were changed to determination method (P459)=posthumous (Q1395509) [1]. --Pasleim (talk) 14:25, 13 December 2017 (UTC)[reply]

Let's solve the initial own first. subject has role (P2868) is fine for de facto, interim, acting. I thought this was resolved as you moved some there already.
--- Jura 13:12, 13 December 2017 (UTC)[reply]
- Looks like Pasleim moves them to "object has role" while Deryck Chan moves them to "subject has role" or "sourcing circumstances". Can we agree on something first than move them around. In the meantime, please move them back to "as". This was created for cases where people can't identify a better one. Which apparently is the case here. Shuffling them around in an random manner is just bad quality editing.
  --- Jura 15:31, 13 December 2017 (UTC)[reply]

Using "object has role" and "subject has role" is not a conflict, it depends on the context which one should be used. I see "sourcing circumstances" to be not wanted according to this discussion. --Pasleim (talk) 15:51, 13 December 2017 (UTC)[reply]

Good point. I double checked the statements and in the context (non-P39 statements) it was actually correct. I also found a few other qualifiers being used: statement is subject of (P805), has cause (P828), occupation (P106). position held (P39), determination method (P459), elected in (P2715) ..
--- Jura 16:17, 13 December 2017 (UTC)[reply]

(edit conflict) The problem with these properties is that they explicitly qualify either the subject of the object. But what we want to qualify here is the verb (main property). When [person] holds position [position] "as" "interim", neither the person is interim nor the position is interim, but rather the action of holding the position is interim. So subject has role (P2868), object has role (P3831), and applies to part (P518) are all problematic matches because they qualify the subject or the object. sourcing circumstances (P1480) is grammatically closer, but it's strictly about the degree of truth rather than the status of the statement. @Swpb: This mismatch is why I think there should be an "status of statement" / "applies to aspect" qualifier which is separate from all the ones we've used to port out P794 (P794) so far. Deryck Chan (talk) 16:29, 13 December 2017 (UTC)[reply]

I see the argument that subject has role (P2868) isn't an exact fit, but I'm hesitant to add to the qualifiers without cleaning up the definitions of the existing ones. criterion used (P1013) and determination method (P459) serve closely related purposes, for example. And "applies to aspect" is an alias of applies to part (P518). It should be clear which is the "right" property for any given case, so we don't end up with a mix. Swpb (talk) 21:06, 13 December 2017 (UTC)[reply]

I again restate, in the examples given the truthfulness of interim/acting/... is not in argument, so application of P1480 is simply incorrect. Where the "position held" is being described, noting that the position should be specific, the "subject has role" of interim or acting is not describing the person as interim but their qualification of the position. There is ZERO relevance about the sourcing. — billinghurst sDrewth 23:20, 13 December 2017 (UTC)[reply]

If we agree that "sourcing circumstance" is not pertinent, I also think that the discussion here about "the where" they should be moved. It either belongs back at "as", in Project Chat, or at a discussion about your new proposal. — billinghurst sDrewth 23:24, 13 December 2017 (UTC)[reply]

@Deryck Chan: What would you think about calling your new property "condition of statement", and making it a parent of several of the more specific qualifiers? "Condition" is broader than "status" ("status" being a time-dependent condition). "Condition" would be a good fit for interim/acting and de facto/de jure, and probably quite a few other things itself, and it would be a natural parent for sourcing circumstances (P1480), criterion used (P1013), determination method (P459), and maybe others. I think it could capture the generic-ness that Jura1 is looking to retain without being as hopelessly generic as P794 (P794). I would happily support such a property. Swpb (talk) 13:53, 14 December 2017 (UTC)[reply]

One could argue that the three don't necessarily need the same qualifier. "de facto" has nothing to do with "interim" or "acting". The "acting" can be "interim", but not all "interim" are just "acting". The exact meaning might depend on the function and could just have been picked randomly among the options when adding data. There is nothing conditional about someone filling a function as "acting", it's just a special mode of acceding to the function.
--- Jura 15:30, 14 December 2017 (UTC)[reply]

They don't need to use the same qualifier, but I think the fewer qualifiers it takes to cover all cases, the better – and I thought that's where you were coming from too, with wanting to retain P794. I don't agree with your last sentence: I think you may be assuming a different use of the word "condition". I'm not saying that [item][has position][position] is conditional (dependent) on it being an acting position, but just that [acting] is a condition (or mode, or quality) that is true of the statement. Swpb (talk) 15:43, 14 December 2017 (UTC)[reply]

Redacted not part of sourcing circumstances (P1480)[edit]

Copied from User talk:Ipoellet: P1480 is about the truthfulness of the value, whereas "redacted" is about a statement in the source in a work, not about the truthfulness of the value. As such you shouldn't be using P1480 to indicate that a reference statement is redacted. P1480 is a qualifier, whereas what you seem to be wishing to do use as part of the reference. I have undone your addition of redacted as a suitable qualifier. — billinghurst sDrewth 12:56, 6 February 2018 (UTC)[reply]

@billinghurst: You are incorrect in your analysis of sourcing circumstances (P1480). While some of the currently allowed values are about the "truthfulness" of a statement, such as misprint (Q21096955) or disputed (Q18912752), others are not. For example, near (Q21818619) speaks to the level of precision in a statement that may nevertheless be fully true and accurate. Another example is that official (Q29509043) and unofficial (Q29509080) speak to the adoption of a statement by a particular entity, again regardless of whether the fact is true or accurate. In that context, redacted (Q47851538) in fact is more about "truthfulness" than about the other uses to which sourcing circumstances (P1480) is put: a critical reader will question whether textual excisions act to alter the overall message of a redacted work when compared to an unredacted version, which is very much about accuracy and "truthfulness".

You also appear to wish to restrict the application of sourcing circumstances (P1480) to qualify individual statements to the exclusion of qualifying whole works. Yet I am unable to think of a reason why such a restriction is of use to Wikidata. The property appears to have the flexibility to take on both tasks, which are not so very different from each other. Can you provide your reasoning why restricting the property in that way supports the overall project? And if there is such a reason, what property would you recommend using to qualify the accuracy/validity of an entire work? — Ipoellet (talk) 05:08, 7 February 2018 (UTC)[reply]

@Ipoellet: "near" is a sourcing circumstance where a person is born near to a township and the like, this is often the fact/citation given in a work; as such it qualifies a cited location. The others that you cite are still qualifiers.

When I think wikt:redact I think of information removed from a document, so I am not seeing how that can qualify a stated fact. Can you provide an example of how you were looking to use it?

Earlier discussions, I believe, determine that we're not to use this property as the marker of the reliability of a reference/citation. So you can cite the data point with a document/reference, and deprecate the factoid per Help:Deprecation. I am not saying that redacted is not a suitable note for a reference, I am saying that I don't see it as a qualifier for this property. — billinghurst sDrewth 11:19, 7 February 2018 (UTC)[reply]

New value: hierarchical link is not direct (Q50095342)[edit]

Property broader concept (P4900) has just been approved, as an informative qualifier on statements giving links to external thesauruses like Art & Architecture Thesaurus ID (P1014), Europeana Fashion Vocabulary ID (P3832) etc. P4900 points to the nearest item that has been matched upwards of the present one in the external hierarchy.

This makes possible queries like tinyurl.com/yd9xrkhy that returns all items matched to a particular sub-part of the external tree, and tinyurl.com/ybvwrfnc for items where the upward relationship cannot (currently) be 'explained' by existing subclass of (P279) relationships.

With such relationships, and for queries like the latter, it is useful to be able to indicate if the item pointed to by broader concept (P4900) corresponds to the direct parent of the present item in the external hierarchy; or if the nearest upward item we can match is not the direct one, but one from further up the hierarchy.

In proof-of-concept tests before the new qualifier was approved, I used part of (P361) for the upward relationship, and indicated when this was different to the direct relation recorded in the source with sourcing circumstances (P1480) = hierarchical link is not direct (Q50095342)

This gave statements like eg Q193204#P1014 if the relationship was direct, and Q763457#P1014 if the next upward item matched does not correspond to the immediate parent entry in the thesaurus, but instead a higher-up entry.

Now that the new property has been created, I should like to go through and replace these trial uses of part of (P361) with the now approved broader concept (P4900). But before doing so, I thought I should confirm here whether sourcing circumstances (P1480) = hierarchical link is not direct (Q50095342) is considered acceptable for use, going forward. Jheald (talk) 17:47, 1 March 2018 (UTC)[reply]

Translations are most likely wrong[edit]

See RFC, there are too many translations where either can have benefit to be stored as separated properties, or should just be altered. --Liuxinyu970226 (talk) 02:01, 26 March 2018 (UTC)[reply]

Nonsensical use of "no value" with this property[edit]

enWS has come across examples of use of this property with "no value" which is pretty nonsensical. Can we look to flag such use as being a violation. If it needs to be added, then it should be expected to have a custom value, as I see it. Thanks. — billinghurst sDrewth 09:46, 20 October 2019 (UTC)[reply]

Indeed, is there any restrictions called "do not use no value"? --Liuxinyu970226 (talk) 14:02, 12 March 2021 (UTC)[reply]

Could you give one or two examples of "no value" ? --Bouzinac ^{💬●✒️●💛} 14:26, 12 March 2021 (UTC)[reply]

:::Top of my head :Date of birth:? Otherwise, I cannot remember why I added this, and apologies for not being ore fulsome at the time. Clearly was focusing on something else at the time. — billinghurst sDrewth 04:46, 13 March 2021 (UTC)[reply]

[Oh, check the property first] @Bouzinac: If someone is saying "sourcing circumstances" and labelling it as "no value" how is that a sensible use of the property, either don't add it, or require something that adds a circumstance. — billinghurst sDrewth 04:51, 13 March 2021 (UTC)[reply]

approximation (Q27058)[edit]

For what reason has approximation been excluded as a value for the "one of" constraint? Senator2029 04:18, 13 December 2020 (UTC)[reply]

Adding possible values? For when there are multiple conflicting values[edit]

Can this be used to indicate when a property is uncertain b/c there is a conflicting property (either for the same entity -- two different WikiTree IDs point to this Wikidata entity -- or for a different entity -- this and another Wikidata entity point to the same WikiTree ID)? Genichi-ni (talk) 17:36, 13 December 2020 (UTC)[reply]

Conflict with P1480 to be solved; restrict use to references[edit]

Please comment here. --Epìdosis 17:28, 22 June 2022 (UTC)[reply]

Sourcing circumstances for precise/hard/proven data?[edit]

There are many options for not-so-certain entries ("disputed", "dubious" etc.) but what are the options for hard data? Example: the original size of the Kerch hoard (1988) is estimated from 2 to 3.5 thousand coins. Fine. But the actual amount recovered, preserved and catalogued in the museum is only 521. What are the options for the latter number? Retired electrician (talk) 23:09, 18 November 2022 (UTC)[reply]

lunisolar calendar[edit]

I noticed several non Gregorian or Julian calendars were included for use as constraint or qualifier. Is there a reason that lunisolar calendar does not meet the criteria for <sourcing circumstances>? Thank you. jshieh (talk) 15:30, 4 January 2024 (UTC)[reply]

"Search for values" doesn't work[edit]

At the end of the documentation work there is a "Search for values" field with a query example: "haswbstatement:"P1480=Q5727902", and it doesn't work. Nikolay Komarov (talk) 13:29, 13 February 2024 (UTC)[reply]

Add value "documented" or similar?[edit]

The possible values for this property all indicate various levels of doubt about a statement. I have a dataset where most of the statements are reliably sourced, but a few are unclear, so I would like to use this property, but would need a value like "documented" or similar. Would that be possible or is there a reason why all the values are about dubious sourcing? Lijil (talk) 15:33, 22 March 2024 (UTC)[reply]