ClaimReview needs field for URL of claims / integration of new Claim type #1828
Comments
|
Thanks @BillAdairDuke, good to get this discussion moving. I agree there's an issue here and it is important to find a pragmatic solution. One quick clarification about sameAs, ... it has potentially several roles in that it can be used on each typed entity, whether we're talking about the (Claim)Review, the Person, or a CreativeWork like NewsArticle. Conceivably there could be several sameAs properties in a single description. Regarding "claimUrlOriginal", does this always indicate the URL of the itemReviewed? If so we could potentially make it an "url" property of that entity. Some of the same issues might also be addressed by introducing a new type that more explicitly represents the actual claim under discussion. So if the claim is that "The moon is made of green cheese", right now Schema.org only represents that fairly indirectly; we talk about a review of that claim and then kind of casually mention the claim in passing via the claimReviewed property. In other words our current model is very much oriented around a bottom up way of dealing with claims as they occur, rather than attempting to normalize them into abstract claims that are unrelated to their occurance in real life. My impression is that by introducing claimUrl we would be getting into very similar territory. Are there factchecking-oriented sites that try identify claims quite separate from their specific occurrences? |
|
Thanks for the feedback, Dan. Answers below, with a request for clarification. Regarding "claimUrlOriginal", does this always indicate the URL of the itemReviewed? If so we could potentially make it an "url" property of that entity. Yes, “claimURLOriginal” would always indicate the URL of the statement that is reviewed. In some cases that would be the URL of a text or speech. It could also be a news article that contains the claim in a quote of the person. Some of the same issues might also be addressed by introducing a new type that more explicitly represents the actual claim under discussion. So if the claim is that "The moon is made of green cheese", right now Schema.org only represents that fairly indirectly; we talk about a review of that claim and then kind of casually mention the claim in passing via the claimReviewed property. In other words our current model is very much oriented around a bottom up way of dealing with claims as they occur, rather than attempting to normalize them into abstract claims that are unrelated to their occurance in real life. My impression is that by introducing claimUrl we would be getting into very similar territory. Are there factchecking-oriented sites that try identify claims quite separate from their specific occurrences? I’m not clear what you mean in that the schema represents the claim “fairly indirectly.” In practice, it seems to me that it’s clear that “itemReviewed” is what is being fact-checked. I don't think there's been any confusion about that by users. I’m also not sure what you mean by “rather than attempting to normalize them into abstract claims that are unrelated to their occurance in real life.” Are there factchecking-oriented sites that try identify claims quite separate from their specific occurrences? Also not sure what you mean here. If you mean, "Do fact-checkers distinguish repeated claims?" - Practices vary. Some publishers, such as the Washington Post, will put multiple similar statements by different people at the top of an article, although not in any structured way. Others, such as PolitiFact and Snopes, will just mention in the text that the claim or a similar one has been repeated by others. This is particularly clear with talking points that get repeated by many politicians and publications. |
|
Dan -- basically, we're trying to make a distinction between the entity responsible for a claim and places where the claim has appeared. Currently we have the former but not the latter. |
|
Hi All, Here is my take on this.
Assuming this is our common understanding, we have two options to model as many instances of the claim as possible:
(We do note that claimUrl is not used to capture merely reporting pieces. For example, if XYZ said 'earth is flat' and publisher A writes an article saying 'XYZ says earth is flat,' A's article shouldn't be modeled as claimUrl.) At a high level, claimReviewed, claimUrl, claimUrlOriginal are all attributes of ClaimReview, it seems to be pretty well organized as a unit. Dan, what do you think? We want to get the definition into the pending schema as soon as possible, so the journalists can start using it. |
|
Thanks, that all helps me understand where you're coming from. By indirectly, what I mean is that we have made the review of the claim the focus, and there is no type in schema.org that actually represents the claim itself. We have types for the factcheck reviews, the people, documents, etc but we haven't yet introduced an item (that can have relationships to and from other items) representing the Claim. Maybe we don't need to.
I'd put it slightly differently. None of these fields are mandatory in schema.org, sites can say as much or as little as they like. But by handling the itemReviewed as the occurrence of the claim, not the idea itself, yes it does potentially come with more baggage. Which was why I'm (tentatively) floating the possibility that we might want to have a type like "Claim" that could just represent the idea being checked, not the article or tv show or whatever where it showed up. Let's not talk about this for ages but I did want a little discussion on this point before we move to get the properties into Pending. How about we aim at having new terms in Pending by the end of next week, unless we cook up a better idea here in the meantime? |
|
Sounds good, Dan, let's wait till end of next week in case someone comes up with a good idea. Agreed, ClaimReview is review focused. I am a bit hesitant though to create a Claim type since it might be very confusing to people with itemReviewed also representing (an instance of) the claim. I think the rationale for keeping claimReviewed, claimUrl, claimUrlOriginal under ClaimReview directly is that they are all identified/extracted by the fact checker, not the claim maker, so it belongs more to the ClaimReview. |
|
We are adding more and more properties about the claim, including the URLs. It would be better to create a proper class for Claims and put the properties on the class rather than shoehorning into ClaimReview. |
|
I agree with Vicki. Claim should be a first class object. It does add one
level of indirection, but that could be super useful.
There are very long running claims (e.g., Birther, Gardasil, etc.) for
which someone can assign stable identifiers and once we have enough data,
build classifiers, etc.
guha
…On Wed, Jan 24, 2018 at 9:46 AM, vholland ***@***.***> wrote:
We are adding more and more properties about the claim, including the
URLs. It would be better to create a proper class for Claims and put the
properties on the class rather than shoehorning into ClaimReview.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1828 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAlCgXYaLq6sklGO3NaVFfMyLTpQhDHks5tN2x_gaJpZM4RoQBe>
.
|
|
The itemReviewed within ClaimReview is in fact the claim, or more accurately, an instance of the claim. If we introduce a new Claim type, are we going to cause more confusion among the journalists in terms of the relationship between the two? Or are we talking about replacing itemReviewed with claimReviewed? (I am worried about backwards compatibility with the existing markups here ...) |
|
@cong-yu my recommendation would be for reviews to stick with itemReviewed, regardless of what exactly the review is of. We already are getting reasonable questions about how to handle things like TV clips / videos, where there are two "candidates" for the item reviewed: the specific clip versus the larger material (e.g. 20 seconds vs 1 hour). Naturally it is good to have both documented, and for there to be a well known way of associating them with each other (and directly or indirectly, with the review). The TV discussion (instigated by the Archive.org folk, who I believe are also in touch with @BillAdairDuke) is in #1686 For the TV clip case, here is the draft approach I've sketched: https://gist.github.com/danbri/96d6265756577e5f21ad4141f053b76d ... Here is a cut down subset to show the structure: {
"@context": "http://schema.org",
"@type": "ClaimReview",
"datePublished": "2017-07-06",
"url": "http://danbri.org/2017/TODO",
"claimReviewed": "In the middle of the Cold War, the United States played a role in the overthrow of a democratically-elected Iranian government.",
"reviewBody": "This claim is true. The UK also played a role.",
"itemReviewed": {
"@type": "Clip",
"startTime": "350",
"endTime": "370",
"duration": "20",
"isPartOf": {
"@type": "VideoObject",
"url": "https://www.youtube.com/watch?v=B_889oBKkNU",
"name": "Clip from President Obama Speech to Muslim World in Cairo",
"transcript": "http://www.nytimes.com/2009/06/04/us/politics/04obama.text.html"
}
}
}In this case, we're saying "there's a ClaimReview, and its itemReviewed is a Clip, which isPartOf a VideoObject". If we explore the push from Vicki and Guha towards adding a Claim type (and which I agree will be very useful eventually), then we have some similar choices to make. Two analogous structures would be as follows. One has a review-claim-work structure, the other is review-work-claim. Variant 1: "the review's itemReviewed is a Claim, which has a claimedIn of the materials carrying the claim occurence." (review-claim-work) {
"@context": "http://schema.org",
"@type": "ClaimReview",
"datePublished": "2017-07-06",
"url": "http://danbri.org/2018/TODO",
"claimReviewed": "The moon is composed largely of green cheese (maybe with some patches of Camembert).",
"reviewBody": "This claim is false, people have been there to check.",
"itemReviewed": {
"@type": "Claim",
"The moon is made of green cheese.",
"url": "https://en.wikipedia.org/wiki/The_Moon_is_made_of_green_cheese",
"claimedIn": {
"@type": "VideoObject",
"url": "https://www.youtube.com/watch?v=B_889oBKkNU",
"name": "LUNA LACTOSE NEWS: 10 Green cheese facts the MSM don't want you to know"
}
}
}This is however a bit awkward, since the more canonicalized/abstracted claim is sandwiched between the two items (the review and the VideoObject or Article etc) which describe its occurence. This is fine for a single fact check but gets messy if you merge descriptions of multiple occurences since there is then no association from review to the specific article being reviewed. Variant 2: "the review's itemReviewed is a CreativeWork that carries an occurence of a Claim, indicated via embodiesClaim." (review-work-claim) {
"@context": "http://schema.org",
"@type": "ClaimReview",
"datePublished": "2017-07-06",
"url": "http://danbri.org/2018/TODO",
"claimReviewed": "The moon is composed largely of green cheese, with some patches of Camembert.",
"reviewBody": "This claim is false, people have been there to check.",
"itemReviewed": {
"@type": "VideoObject",
"url": "https://www.youtube.com/watch?v=B_889oBKkNU",
"name": "LUNA LACTOSE NEWS: 10 Green cheese facts the MSM don't want you to know"
"embodiesClaim": {
"@type": "Claim",
"url": "https://en.wikipedia.org/wiki/The_Moon_is_made_of_green_cheese",
"The moon is made of green cheese."
}
}
}If we continue down this route we will need to consider whether the Claim here is the exact claim represents in some NewsArticle/VideoObject etc or represents the more general idea that is likely surfacing in many places. For now I've assumed it is somewhat abstracted, but that urls might be available for very well known claims - either at Wikipedia, or aggregations from the fact checking world, initiatives like DebateGraph etc. However If each occurrence of the Claim type really just represents a specific occurrence of a claim in a particular work, then variant one above could also be viable. I haven't tried to mix together the TV Clip situation with the "model Claim explicitly" approach yet, but wanted to mention it here as there are similar structural issues, namely that we have to figure out which things get modeled with itemReviewed and which with other properties. We ought also to consider whether one ClaimReview can have multiple claims/items being reviewed, or it is better just to repeat the entire structure for every (occurrence of a) claim. |
|
Thanks Dan. I just chatted with Guha and now better understand the desire for a "Claim" object that would be viable on its own, separate from the enclosing ClaimReview. However, to Cong's point, it will impose substantial hardship on overstretched fact check techies if we break the existing schema. Here's a thought, building on your proposed variant 1: what if Claim extended CreativeWork, kept the existing "author" semantics that we're using live, and added a field called something like "appearance" that could be an organization, person, VideoObject, etc. Thus, fact checkers who don't want to use the new "appearance" field could keep using their existing markups with no breakage, but going forward we have a richer concept of a Claim for those who want to express additional characteristics or use them outside the context of a ClaimReview. |
|
@danbri If introducing claimUrl and ClaimUrlOriginal is absolutely a no-go, then I think reusing itemReviewed is a good compromise. Below is an example markup that corresponds to @BillAdairDuke's example. It fits well with the additional types you are creating. It is, however, not a Claim type, and it is not clear to me how to introduce an attribute that denotes the meaning of "original" since it does not make sense for general review. It is also not necessarily backward compatible since the current implementation assumes there is just one itemReviewed and that's where the claimant is extracted. @jkosslyn Is it possible for you to create an example markup for me to understand exactly what you mean? I don't really like the above approach and would like to see what alternative proposal is there. |
|
@cong-yu sure thing, here's what I mean. Very similar to your proposal, but with only a single itemReviewed of type "Claim," and containing several instances of "appearance" in addition to the "author" field. The underlying logic is that a review can only really be of a single claim (otherwise how can the review come to a single rating?). If that single claim appears in multiple places, we could use the "position" field or somesuch within each appearance to indicate the first appearance vs follow-on appearances. Follow-on thought: Perhaps we don't even need a new "appearance" field at all, and the existing "workExample" field might suffice, depending on how that field is currently used in practice? |
|
Disconnected thoughts:
|
|
@jkosslyn thanks, I revised your code so it parsed correctly and uses workExample. I think we are getting somewhere with the great discussion. See my comment after the code. Given all the proposals, let's take a look at the following scenario. Say for example, Publisher A originally publishes an article AA spreading a rumor. Politician X notices that article and spreads the same rumor in one of his speeches. Publisher B reports the speech in an article BB, which also spreads the rumor. Fact checker C comes in and fact checks X and writes the fact checking article. In the less semantically rich first proposal (claimUrl, claimUrlOriginal), the itemReviewed will be about X making the speech, which links to the official speech site, while claimUrl and claimUrilOriginal link to BB and AA, respectively. This works because the itemReviewed, claimUrl, claimUrlOriginal are equivalent, all are just instances of the claim. In the more semantically rich current proposal with workExample, the one stored inside itemReviewed gets the elevated status because it is the root element containing all the workExamples. Thus, in this case, should the speech be in the itemReviewed or the article AA? If the former, the semantics is a bit weird since politician B is not the original claim maker. If the latter, what about cases where the original claim maker can not be identified? So this may be at the root of the discussion: if we want to capture Claim as @chaals and many on this thread are aiming for, what fields really identify a Claim? So far, we have pretty good fields to identify instances of a Claim, but not really a Claim in the sense that can unify all the instances. Is it possible that we don't actually have that information for most cases? |
|
@cong-yu that proposal LGTM, @danbri what do you think? @cong-yu in terms of the scenario you pose, the claim would be the rumor as asserted by Publisher A in article AA, and as amplified by Politician X and Publisher B. If the amplifications cite the original claim by Publisher A, then they would be workExamples; if the amplifications don't cite AA but rather assert the claim as fact, then they could be considered new examples of the claim with new authorship by Politician X and Publisher B. In terms of the general principle, I think you're right that some Claims will have more fields and some will have less; some will be unified and some may be disjoint; etc. This seems to be a fundamental, unavoidable fact of the messiness of the real world. If there are enough instances of Claims with overlapping fields, perhaps they could be programmatically merged, at least in some cases. |
|
This direction is looking good, but let me check something. Good idea to reuse workExample, but is it intended that it is attached to the ClaimReview not the Claim (which was where "appearance" was shown in Justin's original). |
|
@danbri Good call, that was a typo, fixed. @jkosslyn a bit confused here, are you suggesting the following: If the instances of the claim are independent (i.e., no citation connection), we should model them as separate itemReviewed; if they form a citation chain, we model them as workExamples where the one everyone cites becomes the itemReviewed? That seems too complicated semantically to maintain and also not backward compatible. Perhaps we can assume within a single ClaimReview, the instances of the claim are always connected and the reporter can simply use their judgement to pick one that gets the itemReviewed's author/datePublished treatment? |
|
@cong-yu @jkosslyn having a single itemReviewed seems a little simpler conceptually to me, and consistent with the way other kinds of reviews are handled. But it can be awkward (as it was with the TV video vs smaller clip example) since you have to somewhat arbitrarily pick one entity as the focal point, even if the others can also be associated via relationships. I would like to leave open the possibility (beyond the fact check review usecase) of having Claims relate to Claims, eg. well known claims having well known URLs. I'm not sure if there is a need for Claim-to-Claim metadata within typical fact check claim reviews though. We can probably get away with using sameAs URLs for the well known links, to keep the review markup simple. Here's an example I've had in mind for a while, https://debategraph.org/Stream.aspx?nid=33108&vt=rgraph&dc=focus - debategraph's representation of the (claim that) "the 1953 coup deposed the democratically elected Mosaddeq government". Actually that is a pretty mild claim, the stronger claim is the more specific one that CIA and MI6 were the initiators of the coup. By having an explicit representation of these (increasingly detailed) claims, decoupled from any specific fact check review, we get an interesting foundation for linking this kind of data together. |
|
@danbri agreed, having a single itemReviewed is conceptually clearer to me as well. I noticed that Clip inherits from CreativeWork; could we allow the itemReviewed to be any subclass of CreativeWork? As long as it has a url field, adding more optional fields wouldn't hurt the core usecase. @cong-yu If the instances of the claim are independent (i.e., no citation connection), I think we should model them as separate ClaimReviews. I.e. two independent claims with two independent sources and contexts means two independent reviews. After all, in fact checking we've seen so many cases where the context tips the scales of the review. Of course there may always be corner cases where citations are not explicit but are implied; in those cases editorial judgement would make the call. |
|
@jkosslyn - for a ClaimReview it may make sense to encourage only CreativeWork. There are other kinds of reviews too (cars, hotels, employers, ...), but they at least can share the common structure of having a single focal itemReviewed. In passing (and wary of distractions), we should also note for the record that there may be some commonalities between Claim(Review) markup and Question/Answer sites. That does not mean we need to converge the two forms of markup, but it is worth bearing in mind that e.g. matters of historical or scientific fact are often debated on sites that are structured in terms of questions and candidate answers. For example: https://history.stackexchange.com/questions/26495/how-secret-was-the-us-and-british-involvement-in-the-1953-iranian-coup-d%C3%A9tat?rq=1 (see data extracted by Google). |
|
OK, I think we are getting to some consensus. The remaining question is that, given we are not introducing new field, do we really need a new Claim type? I do think there is value in introducing Claim type on its own, independent of the ClaimReview, with all the benefits of linking everything together, but it does sound like beyond the scope of this current extension to ClaimReview? |
|
@cong-yu isn't the ability to say what we need without adding more custom properties a feature not a bug? |
|
@danbri do you mean we can introduce the Claim type without needing to add a new field? |
|
We could. |
|
Yes, we can add the new type (Claim) without a new property/field.
a ClaimReview could either have a particular article as its itemReviewed or
a Claim.
e.g., consider the claim that Lee Harvey Oswald did not act alone. This is
a claim that has been restated in thousands of articles. Rather than
picking one of these articles to be the itemReviewed, it could be the
abstract Claim.
This construct could be useful for science, medical and other fact
checkers who don't want to point to some particular publication and say
that it is false, but rather, more abstractly, provide evidence for or
against some claim/theory.
guha
…On Mon, Jan 29, 2018 at 6:42 AM, Dan Brickley ***@***.***> wrote:
We could.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1828 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAlCtVlUNPwW8RN8BGCZB93lzIPKD5Bks5tPdjDgaJpZM4RoQBe>
.
|
|
Claim: Guha is intelligent. All humans have intelligence. Sometimes :) +1 for new Claim type. |
|
Claim will be a subclass of CreativeWork.
guha
…On Mon, Jan 29, 2018 at 9:00 AM, Cong Yu ***@***.***> wrote:
@rvguha <https://github.com/rvguha> @danbri <https://github.com/danbri>
Sounds good, in terms of backward compatibility implementation, can we have
the itemReviewed be of both Claim and CreativeWork type?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1828 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFAlCmNCjxFmgf7JT4y0MCjY-9aqWRTcks5tPfkmgaJpZM4RoQBe>
.
|
|
Hello all! I'm head of operations and development for Snopes.com. I integrated the claim review mark-up into Snopes' WordPress Theme. I spent a lot of time thinking about this markup because it relates to the other projects I am working on like a misinformation triage engine and a commercial API. The ClaimReview process is built into our fact-check template with a simple UI for our staff. My staff never sees the schema; they fill in fields I labeled in a way they understand. I've reviewed the thread and wanted to chime in with Snopes' position on the markup:
I know I jumped in very late, but I hope this is helpful. I can be reached directly at vinny@snopes.com Snopes Ideal Schema |
|
I've been looking into the consequences of this for neighbouring pieces of Schema.org, i.e. non fact-checking reviews. I have opened an independent issue on that, since Schema.org needs to have a clear picture of when/whether itemReviewed can be repeated. I believe we can make this work and just need to do the housekeeping to keep related definitions in sync. I'd like to say
|
|
@danbri Some notes for you: From my perspective, the item(s) being reviewed should purport the claim being reviewed with little left to the imagination. Allowing for variation could make understanding the data and using in applications more difficult. If this data is being utilized in an application, it's easier to convey that the item's being reviewed strictly match the claim. Otherwise, we would need the publisher to express the reason or theme of the reviewed items. This might stretch the definition of "claim" and cause more issues. When considering how multiple itemRevieweds can be deployed across other subtypes, we need to consider if it multiple distinct Reviews is more appropriate. More clearly, is the need for many itemRevieweds solved by having many Reviews on the page? We build collections of ClaimReviews in our archives. We convey the theme on the page through the title and description and included many ClaimReviews. Google uses them in the knowledge panel currently. |
|
FYI The following is the example code taking Vinny and Dan's comments into consideration. It leverages the repeatability of itemReviewed, which Dan is hoping to get approved soon. No new type or attribute is introduced (Claim type is already being proposed in a separate issue). Regarding the granularity of the repeatability:
Vinny has a good point on being careful about the variants of the claim (whether two claims are really different or simply slight variants of the same), it is an editorial call and the idea is that each publisher should think carefully about that and use either 3 or 1/2 as appropriate. |
|
Thanks @cong-yu - we already added Claim (with the usual 'pending' status for new things) in this last release. Wouldn't we rather use the "appearance" (and even "firstAppearance") properties to link from the Claim to the CreativeWork? (rather than workExample) There's also no strong need to multiple-type ("@type": ["Claim", "CreativeWork"]); Claim is a defined in the schemas as a CreativeWork so the extra info doesn't add much except page weight. |
|
One variation we often see in political fact-checking is similar but not identical claims. For those the fact-checkers would have to judge if they are similar enough to count them as the same.
So would that be a be a fourth variation in your options, Cong?
4. Similar claim => use different ClaimReview (but somehow designate its similarity?)
From: Dan Brickley <notifications@github.com>
Reply-To: schemaorg/schemaorg <reply@reply.github.com>
Date: Monday, July 16, 2018 at 4:20 PM
To: schemaorg/schemaorg <schemaorg@noreply.github.com>
Cc: Bill Adair <bill.adair@duke.edu>, Mention <mention@noreply.github.com>
Subject: Re: [schemaorg/schemaorg] ClaimReview needs field for URL of claims (#1828)
Thanks @cong-yu<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cong-2Dyu&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=odB38y03SUVmQ74epVt2nA&m=KYz29kdtc0SYiCP-mIMYLaQxEvk0oMQHwAT9jZ49o78&s=XG3Qba8v1T8pOWf_1woLNALfd7be_R1P9bkWE9-uB20&e=> - we already added Claim (with the usual 'pending' status for new things) in this last release.
Wouldn't we rather use the "appearance" (and even "firstAppearance") properties to link from the Claim to the CreativeWork? (rather than workExample)
There's also no strong need to multiple-type ("@type<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_type&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=odB38y03SUVmQ74epVt2nA&m=KYz29kdtc0SYiCP-mIMYLaQxEvk0oMQHwAT9jZ49o78&s=s0Y8nQyT6C2wJ1aRfzM3Ahb4Pm068BXfn-obfP7uYDc&e=>": ["Claim", "CreativeWork"]); Claim is a defined in the schemas as a CreativeWork so the extra info doesn't add much except page weight.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_schemaorg_schemaorg_issues_1828-23issuecomment-2D405368898&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=odB38y03SUVmQ74epVt2nA&m=KYz29kdtc0SYiCP-mIMYLaQxEvk0oMQHwAT9jZ49o78&s=f_Q1hlbWza4Jsd2yKM0ksQHTeu7Q9onUjWztCXskhCA&e=>, or mute the thread<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_Ah0q6-5FoObxo-2D5tMkKPnDwDGmB4RFfn-2DJks5uHPWZgaJpZM4RoQBe&d=DwMFaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=odB38y03SUVmQ74epVt2nA&m=KYz29kdtc0SYiCP-mIMYLaQxEvk0oMQHwAT9jZ49o78&s=X_rDk2uNqckVBf9zvWklmxlE80xKR8UTG7pxbmASY3E&e=>.
|
|
On 16 July 2018 at 13:30, BillAdairDuke ***@***.***> wrote:
One variation we often see in political fact-checking is similar but not
identical claims. For those the fact-checkers would have to judge if they
are similar enough to count them as the same.
So would that be a be a fourth variation in your options, Cong?
4. Similar claim => use different ClaimReview (but somehow designate its
similarity?)
Now that we have a type for Claim, it does open up some options in this
area. We have to be careful not to make things too complex, but one idea
would be to use relationships between several Claims. This could be done as
conventions on top of the basic pattern described here. In the markup this
could be either through nesting or through assigning simple IDs to each
Claim, so that we could point from one claim to another.
For example, if the reported public speech was in some way ambiguous,
perhaps a context which was open to multiple interpretations (e.g. vague
geographic or temporal aspects), you might want to write down several forms
of the Claim. Similarly with translations (we already
have translationOfWork and translator properties for general use). This
could be used either in the case of fact checks written for a
multi-language audience, or when the source language differs from that in
which the fact check is being written (e.g. western writing about Israel,
Iran political speech).
I wouldn't want to get too far into these sorts of cases without staying
close to real world examples. Bill - could you share any that you think
give a good illustration to guide us here?
This could potentially work either by having several ClaimReviews, or by
repeating itemReviewed in simpler cases, depending on where we draw the
line. It would be good to have some clear wording for this, i.e. for when
to break out a different ClaimReview. My feeling is that if broadly the
same family of specific claims by the same speaker is being discussed, a
single review may be natural. But there will be lots of times when it'll be
more natural to have several reviews.
|
|
@danbri yep, appearance should work as well, I will update my comment @BillAdairDuke Yeah, I would leave it to the fact checkers to determine how similar two claims are to each other that a single ClaimReview is warranted ... @danbri this is something hard to concretely define since it is somewhat subjective, and I would not try to clarify this too much ... |
|
@danbri FYI using just Claim still gives error in SDTT so I will keep both for now. |
|
@cong-yu - then let's update the Google tool! And yes, I agree re hard to define. Maybe something soft like:
|
|
@BillAdairDuke @vinnygreen can you help us with some guiding examples from Snopes, Politifact or elsewhere that exercise some of the variations we've discussed above? For example, @cong-yu 's list, |
|
How about this:
Mitt Romney:
Says Barack Obama began his presidency "with an apology tour."
https://www.politifact.com/truth-o-meter/statements/2012/oct/17/mitt-romney/mitt-romney-says-barack-obama-began/
Several times, Obama "has apologized for what he deems to be American arrogance, dismissiveness, and derision; for dictating solutions, for acting unilaterally ... ."
https://www.politifact.com/truth-o-meter/statements/2010/mar/15/mitt-romney/obama-remarks-never-true-apology/
President Obama "went around the world and apologized for America."
https://www.politifact.com/truth-o-meter/statements/2011/sep/22/mitt-romney/mitt-romney-repeats-claim-obama-went-around-world-/
|
danbri
changed the title
|
Here's some text towards documenting how all these constructs can fit together...
|
|
Bill, Cong,
Can you review this?
guha
|
|
+Simon Baumgartner <simonba@google.com>
|
|
@rvguha - Simon and I wrote this together. /cc @cong-yu We were originally thinking of it for Google's own documentation but it felt like a better fit for Schema.org. @tmarshbing - can you take a look from Bing's perspective too? |
|
The key concepts you outline are semantically correct and make sense to me. Can we run this by one or two fact checkers to see whether this makes sense to them? |
|
Thanks @sens3, that's why we're here. I've pinged a few folks by email and Twitter who might not be monitoring Github closely, too... Some of the flexibility we can nudge people away from for now (e.g. having claimReviewed be anything other than a string is not needed until there's a strong demand for multi-lingualism and clarity about translations). But a lot of it comes with the territory, as soon as the question of multiple appearances of the "same" claim - made by different parties, reported in different places - is considered. I would love to tighten things down to a few core patterns and have examples of each, so long as we're consistent with the direction that that fact checking community is headed. |
|
@danbri Can you build out the an empty example schema with all the bells and whistles? I can hunt down some real examples that mirror the possible complexity and fill in the schema. |
|
Hi @vinnygreen - thanks. Here's a fairly simple example @sens3 and I been talking through. Essentially the evolution is from having a CreativeWork (e.g. some news article) be the value of "itemReviewed", to having a Claim there. Then we can point from that Claim to its appearances in the press etc., using "appearance". This helps avoid ambiguity when we want to distinguish authors of articles and claims. |
|
I’ll jump in and agree that ambiguity will lead to paralysis for anyone not used to relational databases and systems. Having any data nested more than one level, two at the extreme, is, from my perspective, untenable. From the journalism perspective every field should, ideally, have one and only one right way to fill out. It’s easier for me to explain how to shoe horn something than it is to remember options. |
|
It seems, from the specification, that a So there would be an interest in modifying the order and adding a new This may alternatively be scattered throughout a news piece with a handful of reviews as an extension of a link that can be link to a fact checker. Then the fact checker can provide a |
|
This issue is being tagged as Stale due to inactivity. |
github-actions
bot
added
the
no-issue-activity
|
After discussing the use of ClaimReview with fact-checkers, there is confusion among the fact-checkers about how to populate the field for SameAs field. Some fact-checkers have been using for the URL of speeches or articles where the claim appeared to provide evidence and details of the claim; others have been using it for the home page/knowledge base article on the person or entity that made the statement.
Both have value for search engines and other uses. It’s valuable to be able to see a knowledge base article on the person or entity being checked; it’s also valuable to be able to see where a false claim was published, particularly the article or speech where the claim originated.
The solution: We propose that:
sameAs will continue to be used for the entity or speaker that made the the claim (we called it the “who to blame” field). This field would typically be the home page of the person making the claim, or their Wikipedia page.
We will add a field(s), under ClaimReview, called claimUrlOriginal of type URL to designate the URL of the origin of a claim such as a speech or article; fact-checkers could include additional URLs (claimUrl) of type URL if the claim has been repeated in other publications.
For example, here is a fact-check by PolitiFact of a claim by New Century Times. The SameAs field is the website’s URL. The claimURLOriginal field would be the article that contained the claim that was fact-checked. That claim also appeared on Vote.us.org, which is listed as a claimURL.
Edited 2018-01-23 by @danbri to highlight key terms, omit HTML script tag, improve formatting.
The text was updated successfully, but these errors were encountered: