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 <lrosenth@adobe.com>
wrote:

> 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 <sandro@w3.org>
> *Date: *Monday, January 20, 2020 at 11:31 AM
> *To: *Credible Web CG <public-credibility@w3.org>
> *Subject: *CredWeb Plans, meeting tomorrow
> *Resent-From: *<public-credibility@w3.org>
> *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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Freport%2F20181011&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773166117&sdata=crklo%2BV%2Fd3jXk81xhTGEZOkPQOI2GchDSnl78NLYpYo%3D&reserved=0>".
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals-beta%2F&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773176102&sdata=wudd1sqpDauLcCj%2BGi1a5NlWL5JbUwyHSLvC02imc%2Fk%3D&reserved=0>
> 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 https://data.credweb.org
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata..credweb.org%2F&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773186099&sdata=PVwsL4BZd2%2BDPhnWY8P6DSc6Lrpt3cuwFeVzkOtqXBI%3D&reserved=0>)
> 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 w3.org. 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals-beta%2F%23newsq-highlight&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773186099&sdata=IIqNnICZGW96lI%2FkQVK8rLITp6LmzrfuXAXLnAELhjY%3D&reserved=0>
> are good options here, and there are also some that are doable by hand
> (like these
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs..google.com%2Fdocument%2Fd%2F1ADJX57-xMHIIHrnzEycFrn4fUGQ63SD8hyEHqScYnTY%2Fedit&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773196087&sdata=IAL4tF1%2FHLewLegkPPcomW3dLAOFscsS1k4gNO6H3Zg%3D&reserved=0>
> ).
>
> 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
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.timeanddate.com%2Fworldclock%2Ffixedtime.html%3Fmsg%3DCredWeb%26iso%3D20200121T13%26p1%3D43%26ah%3D1&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773206090&sdata=0e1hoq%2FvKpboYEwhoppSwdu9BcKj4UzEdhO1g8FnNPw%3D&reserved=0>
>
> January 2020 1pm ET
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.timeanddate.com%2Fworldclock%2Ffixedtime.html%3Fmsg%3DCredWeb%26iso%3D20200121T13%26p1%3D43%26ah%3D1&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773206090&sdata=0e1hoq%2FvKpboYEwhoppSwdu9BcKj4UzEdhO1g8FnNPw%3D&reserved=0>
> ,
>
> https://zoom.us/j/706868147
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fzoom..us%2Fj%2F706868147&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773206090&sdata=sYSwM47dIYV%2BO2mwYLXHTmdnlHd1kr1iT3F2nVNubnc%3D&reserved=0>,
> agenda/record
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs..google.com%2Fdocument%2Fd%2F1Zegy2ASbsRtkz8vNVYUXHopZjjXbZweJ5Co8TEW_8w0%2Fedit%23&data=02%7C01%7Clrosenth%40adobe.com%7C852bf2c4271e432523b608d79dc62b78%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151346773216090&sdata=dQWo3Sp3Q0hrs1WKRmglhZAYANFYnvKDOqjCoNPO9rQ%3D&reserved=0>
>
>      -- Sandro
>


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

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