-
Notifications
You must be signed in to change notification settings - Fork 831
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Claim and ClaimReview 2018 tracking issue #1969
Comments
Educational/Occupational Credential schemasWhat are the requirements from fact checking? There are nearby communities looking at this, but with more of a view to JobPosting and related schemas than fact checking. We ought to evaluate the current proposals from the Edu/Occupational credentials community, to see if it meets needs around Fact Check markup (and News Articles generally, /cc @TheTrustProject). A good starting point is https://www.w3.org/community/eocred-schema/2018/05/23/progress-so-far-and-the-beginning-of-the-end/ (/cc @philbarker). We should collect some usecases, e.g. "articles/claimreviews made by people who work for Medical organizations" versus a specific medical credential, e.g. expertise relevant to vaccines. Here is a draft to give a feel for the current level of detail. The modeling is a little indirect to avoid Schema.org having to standardize everything across all territories and fields and to make use of existing code lists and initiatives. ("Notable") Claims in Wikidata
|
|
@danbri Regarding your comments about "scientific dialog and argumentation modeling" and "articles/claimreviews made by people who work for Medical organizations" ... That happens sometimes within our evidenceOrigin. And evidenceOrigin needs to accept a Dataset as well, so I created #1971 MedicalGuidelineRecommendation itself is a "Claim" of sorts and definitely a result of fact checking across Datasets, ScholarlyArticles and consensus opinions by Medical authorities (sometimes in government service). So #1971 needs to be addressed. But we have no way to represent that MedicalGuidelineRecommendation is a "Claim" or some itemReviewed previously by authorities. Need to tie them together somehow. |
|
@danbri having this overall tracking issue is nice, thanks! I also want us to finish the conversation on #1828 as soon as possible since the discussion there has the right scope for fixing the most important issue for the association data. Also, I think alternateName does its job quite well and changing it will cause major implementation issues. |
|
Also TODO: talk to Annotations people (ping @judell @azaroth42) to see if there are idioms expressed against https://www.w3.org/annotation/ that map into Claim(Review), e.g. Hypothes.is - see https://web.hypothes.is/blog/annotation-is-now-a-web-standard/ Are there are public annotation datasets out there with suitable fact checks in? |
|
@danbri I've looked at a lot of ClaimReview data in the wild, and summarized my conclusions here: https://misinfocon.com/how-web-annotation-can-help-readers-spot-fact-checked-claims-ccbf9246dd68. The upshot: target URLs of claim reviews are rarely being captured in a way that would enable search engines, and other actors, to associate target URLs with the claim reviews that target them. Why isn't the example given here, https://search.google.com/structured-data/testing-tool, being followed consistently? I suspect there are two reasons. First, there might need to be more/better guidance about why/how to cite the target URL in the way https://example.flatworlders.com/we-know-that-the-world-is-flat is cited in the example. Second, as I argue in the Misinfocon post, adding ClaimReview data has become one more step in an already burdensome workflow, so streamlining that workflow -- if possible -- seems desirable. It would be ideal to validate these observations directly with the producers of fact-checking-oriented ClaimReview metadata, of whom there are not many. |
|
I would say that Claim is outside of the scope of the (concluded) Web Annotation work. It's a domain specific notion that classifies some web resource or segment thereof. The description of the segmentation is in the Annotation work, via Specific Resources and Selectors. This allows the identification of the segment, and schema could then provide the classification. ClaimReviews seem very similar to Web Annotations with a particular motivation. Something like: Unless ... the Review is the structured data that is provided to assess the Claim, at which point it's the body of the annotation that has the claim as its target. Hope that helps? |
|
Dan –
Thanks for following up on these things. For my part, I’m particularly glad to see you addressing the confusion from the documentation. As I mentioned at Global Fact, I will can have the Reporters’ Lab create a guide / best practices for the publishers that use ClaimReview and will work with the International Fact-Checking Network to educate the fact-checkers.
I’m also glad to hear your support for addressing the confusion over SameAs by creating a field for URL of claims. I really liked the approach that Simon, copied on this, showed in Rome.
I’d love to move this along so we can get the fact-checkers using it, so let me know what I can do to help.
Bill
Bill Adair
Knight Professor of the Practice of Journalism and Public Policy
Director, DeWitt Wallace Center for Media & Democracy
Sanford School of Public Policy
Room 143
Sanford Box 90241
Duke University
Durham, NC 27708
|
|
This issue is being tagged as Stale due to inactivity. |
This is a meta issue to collect materials for improvements around ClaimReview and Claim. It is the successor to our original tracking issue (#1061) which came out of discussions between Bill Adair (@BillAdairDuke) and some of us from Google. We are moving into a new phase of this work as it matures. This issue is the hub for ensuring community, platform and expert issues are tracked and addressed. If an idea is not recorded here, it is unlikely to result in changes to Schema.org definitions or examples.
I will dump a few things here in the description (e.g. as outcomes from GlobalFact5 conference conversations), and then factor them out into distinct issues later. (June 23 2018 note from @danbri)
Tracked sub-Issues
sameAs clarification
It emerges that we have had some communication confusions around the use of sameAs properties.
The documentation we published at Google has contributed to this, in that it did not make sufficiently clear that sameAs is an entirely general purpose disambiguation mechanism that can be used on any entity in any schema.org description. Furthermore, fact checkers and journalists should not be expected to be familiar with all areas of Schema.org and we will need to work hard to communicate our underlying datamodel and approach to machine readable description, as this work is getting more widely adopted.
Richer examples may help. I collected some Wikidata URLs that could be used to show how { "@type":"Person", "name":"John Smith"} could be made less ambiguous.
Some of these are living, some lived recently, some are historical. (At this point there does not seem to be critical mass for modeling historical claims, perhaps that may emerge later).
Examples
We should add more examples showing the diversity and creativity of the fact checking community, and make clear that our goal around ClaimReview (and Claim) is not to impose a structure, but to capture in a machine format the common data patterns implicit in existing and evolving practice.
Claims
We recently (v3.4 release) added a Claim type into Pending area. This has great potential but we need to be clear on several things before removing the "pending" warning flag:
See "“most of the success we got harnessing the crowd was actually in the translations. […] People were very happy to translate factchecks into other languages.” — Alexios Mantzarlis" in @MevanBabakar's crowdsourcing document.
(edited to add...)
Syndication, Sharing, Usage and feed-related concerns.
Note that we have already addressed the desire to indicate expiration dates ("shelf life") in #1687 which was a response to a request from Full Fact (@MevanBabakar / @FullFact).
We may also want to document a pattern for fact check publishers to point to "community norms", conventions that sit above their formal copyright/trademark etc license terms. Some open data publishers are using this to indicate how they request other parties use their data.
Community Norms backgrounder
(This needs moving out to a related or sub- issue.)
(btw this is a different initiative to DataCommons.org). Nearby, discussion of PDDL and Norms in https://timreview.ca/article/122
CC0 followed by norm statement, "Dataverse asks that all users who download datasets from Dataverse’s services follow the following Community Norms.*",
and things like "Crediting any research used with data citations", "Maintaining anonymity of human subjects", "Third Party API Applications".
http://journals.sagepub.com/doi/abs/10.1177/0968533212458431
Next steps...
This is an incomplete list, but it captures some of the hallway conversations from GlobalFact5; to be continued.
There is also the Tech and Check "standards" subcommittee (hello @MevanBabakar again), who are collecting issues related to fact checking, not strictly limited to claim/claimreview, e.g. profiles of NewsArticle to use in automation tool chains, see https://github.com/TechCheckStandards/core/issues
The text was updated successfully, but these errors were encountered: