Re: CredWeb Plans, meeting tomorrow

I believe, though class schedules kept me from meetings last semester and I
am not a developer, that "signal" has a long history in credibility
research as a "marker" to the consumer to indicate if a source is credible
or not.

So the RDF would be a bit of machine readable data as a vocabulary of of
traditional human readable and disagreeable signals of credibility. For
example you may have a currency "signal" that equates to an RDF vocabulary
for publication date.

Please others correct any misconceptions I may have.

Should be there tomorrow, first day of semester, never know what random
meetings pop up.

On Mon, Jan 20, 2020 at 12:32 PM Leonard Rosenthol <>

> I apologize in advance if this is explained elsewhere – but I don’t
> understand the difference you are making between a “signal” and the “data
> format” that an API would use (or might be embedded in an asset).
> I realize that I am coming at this from the side of assets (image, audio,
> video, documents) as opposed to web pages – but to me they are one and the
> same.
> Thanks,
> Leonard
> *From: *Sandro Hawke <>
> *Date: *Monday, January 20, 2020 at 11:31 AM
> *To: *Credible Web CG <>
> *Subject: *CredWeb Plans, meeting tomorrow
> *Resent-From: *<>
> *Resent-Date: *Monday, January 20, 2020 at 11:30 AM
> Hey folks,
> It's a new year, and we've had some quiet weeks.  I'm trying to settle on
> some next steps for the group. Here's what I'm thinking:
> 1. Let's not try to update the report right now. Let's just convert it to
> a "final report", to make it properly archival, with a clear note that it
> was written in 2018. Maybe a short name like "Credibility Tech 2018
> <>".
> If there's sufficient interest in a revision or new reports that are more
> focused later, that's fine, but I don't think it's the best use of group
> time right now.
> 2. Instead of Credibility Signals
> <>
> trying to include everything about signals while also highlighting the good
> stuff, let's split it into three different resources:
> * *Credibility APIs*, a technical guide for how computers should talk to
> other computers to exchange credibility data. Included data formats,
> protocols, RESTful APIs, browser APIs, etc. Not a spec for any of these,
> but an overview of options that are specified elsewhere. I'm thinking we
> can publish a small draft and start to gather input.
> * A *Credibility Data Exchange*, a website for exploring all the signal
> definitions and signal instance data people are willing to make public,
> with clear attribution back to the sources and no endorsement from us. I've
> made a few prototypes over the years (like
> <>)
> but none I was happy with, yet. Maybe this should just be my thing, not the
> group's; that's topic for discussion. (It might help if someone wanted to
> fund this.)
> * *Endorsed Credibility Signals*.  This would be a relatively small
> document, describing 5-20 signals where we have consensus within the group
> that they are pretty good. I'd expect it to change over time with new data.
> The RDF schema for these signals would be published on It would
> intentionally be kept small enough to be manageable, unlike the Exchange as
> past "Signals" drafts. I think some of the NewsQ highlight signals
> <>
> are good options here, and there are also some that are doable by hand
> (like these
> <>
> ).
> So, agenda for tomorrow is to talk about this plan, and if there's time,
> talk about the actual signals we might be ready to endorse.
> If you can't make it to the meeting and have thoughts on all this, email
> could be helpful.
> Meeting, as usual: 21
> <>
> January 2020 1pm ET
> <>
> ,
> <>,
> agenda/record
> <>
>      -- Sandro

J. Gregory McVerry, PhD
Assistant Professor
Southern Connecticut State University
twitter: jgmac1106

Received on Monday, 20 January 2020 19:09:48 UTC