Re: what do we mean by "signal", was Re: CredWeb Plans, meeting tomorrow

Hello,

And, sharing can be enabled via web annotations
<https://www.w3.org/blog/news/archives/6156> effort, which is also used by
hypothes.is

Thanks,

Adeel

On Mon, 20 Jan 2020 at 23:54, Adeel Ahmad <aahmad1811@gmail.com> wrote:

> Hello,
>
> I preferred the older spec on credibility indicators compared to the
> credibility signals. Credibility Indicators was more thorough in coverage
> which is what you would want out of a schema.org creativework
> <https://schema.org/CreativeWork> compliant Credibility schema.
>
> Thanks,
>
> Adeel
>
> On Mon, 20 Jan 2020 at 23:30, Sandro Hawke <sandro@w3.org> wrote:
>
>>
>>
>> On January 20, 2020 4:45:40 PM EST, Leonard Rosenthol <lrosenth@adobe.com>
>> wrote:
>> >> CredWeb is aiming at a social notion of trustworthiness
>> >>
>> >Interesting.  While that might work for web sites/pages – it won’t be
>> >for the assets contained on those pages (or found elsewhere on the
>> >Web).
>> >
>> >Is that direction locked in stone for CredWeb?   Would the group
>> >consider expanding its definition of “Credible” and “Web”?
>> >
>>
>> We don't have a formally approved charter,  so nothing is locked in
>> stone.
>>
>> Can you give me a concrete example of the kind of functionality you're
>> looking for?  I'm not quite sure what it means for a digital asset to be
>> trustworthy.
>>
>> What comes to mind for me is digital cameras attaching time and location
>> and camera ID information to photos in a way that's potentially quite hard
>> to forge (and hopefully also doesn't reveal private information). Is that
>> the kind of thing you're talking about?
>>
>>      - Sandro
>>
>>
>> >
>> >Concerning VC – I think if you forget about the specifics, the idea
>> >that your claim/signal/whatever *must be* “integrity protected” is key.
>> >This is especially true if/when it is separate from the people (and
>> >their trust/reputations) involved.
>> >
>> >Leonard
>> >
>> >From: Sandro Hawke <sandro@w3.org>
>> >Date: Monday, January 20, 2020 at 3:44 PM
>> >To: Leonard Rosenthol <lrosenth@adobe.com>, Greg Mcverry
>> ><jgregmcverry@gmail.com>
>> >Cc: Credible Web CG <public-credibility@w3.org>
>> >Subject: what do we mean by "signal", was Re: CredWeb Plans, meeting
>> >tomorrow
>> >
>> >Mostly we've just been using the email list for announcements, but in
>> >the interest of getting more discussion going, I'm going to offer a
>> >substantive reply, below.  Hopefully the Subject line above lets you
>> >know if you want to read this.
>> >
>> >On 1/20/20 2:32 PM, Leonard Rosenthol wrote:
>> >
>> >> 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 that sounds like an alternative term for what I have been calling a
>> >“claim” (based on the terminology from the Verifiable Claims (now
>> >Credentials) WG at the W3C -
>> >https://www.w3.org/2017/vc/WG/<
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2F2017%2Fvc%2FWG%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628061745&sdata=6OB29t8iZOP4lbjFUGeU6lwgyXqAXOxsaj7akL%2Frb%2Bk%3D&reserved=0
>> >).
>> > Yes?
>> >
>> >Does a “signal” use any sort of technology to ensure authenticity (eg.
>> >hashes or signatures)?  Or is that out of scope or TBD??
>> >
>> >I think the term "signal" is used somewhat loosely, a bit like
>> >"information".  Here's draft text from Credibility
>> >Signals:<
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcredweb.org%2Fsignals%2F%23h.94xsck7qz3ho&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628071751&sdata=thFM%2BN4FillMl2mcVHoLDHfwonSiD8HJJ8ODtVjwIS8%3D&reserved=0
>> >
>> >Our basic model is that an entity (human and/or machine) is attempting
>> >to make a credibility assessment — to predict whether something will
>> >mislead them or others — by carefully examining many different
>> >observable features of that thing and things connected with it, as well
>> >as information provided by various related or trusted sources.
>> >
>> >To simplify and unify this complex situation, with its many different
>> >roles, we model the situation as a set of observers, each using
>> >imperfect instruments to learn about the situation and then recording
>> >their observations using simple declarative statements agreed upon in
>> >advance. Because those statements are inputs to a credibility
>> >assessment process, we call them credibility signals.  (The term
>> >credibility indicators is sometimes also used.)
>> >That's just draft text, and I don't know that everyone agrees with it.
>> >It also intentionally glosses over several levels of meaning that could
>> >have more precise terms.  Some of these levels will speak more to
>> >different kinds of people than others (#2 uses TCP, #4 uses RDF). For
>> >example, consider:
>> >
>> >1. The age of an internet domain can related to its credibility. So we
>> >can talk about this being a signal, maybe called "age of domain". This
>> >kind of information, this "signal", is used informally in practice now,
>> >and perhaps in some automated systems. It's a signal that's moderately
>> >useful because it stops someone from trivially setting up hundreds of
>> >websites, but it's also not all that useful because (a) attackers can
>> >buy old domains on the aftermarket or buy them in advance and let them
>> >sit before using them, and (b) it could penalize legitimate sources. In
>> >this sense, a "signal" is general concept of a type of information.
>> >
>> >2. There are some protocols for finding out the age of a domain.  For
>> >instance, I can open a TCP connection to port 43 of
>> >whois.verisign-grs.com, send "nytimes.com<CRLF>" and get back text that
>> >includes the line "   Creation Date: 1994-01-18T05:00:00Z". We might
>> >call this "credibility data", "signal instance data", or perhaps "an
>> >observation". Loosely, we could call this a signal, leaving implicit
>> >that it's a signal about nytimes.com.
>> >
>> >3. Somewhere between these two, we might define the creation date of a
>> >domain as the isodate timestamp of the moment the domain registrar
>> >originally recorded as the creation of the domain, when it was most
>> >recently created. Or something like that. Trying to be precise. Call
>> >this a signal definition, maybe, or a signal specification. If we want
>> >interoperability between multiple systems producing and consuming
>> >credibility data, I think we need to get to this level. In practice,
>> >for age of domain, we'd want this to line up with the available data
>> >sources. No point in specifying something we can't have.
>> >
>> >4. Finally, there is some kind of standardized format for this data. In
>> >JSON, maybe it's something like
>> >
>> >{"@context":
>> >"https://www.w3.org/ns/cred"<
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2Fns%2Fcred&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628071751&sdata=XmpfoIzjDNbcWs8m2fKcKx9Tbf0N%2BuUleQvoh8WPU4U%3D&reserved=0
>> >,
>> >
>> >  "domain": "nytimes.com",
>> >
>> >  "created": "1994-01-18T05:00:00Z"
>> >
>> >}
>> >which might come out in Turtle as
>> >
>> >[] cred:domain "nytimes.com"; cred:created
>> >"1994-01-18T05:00:00Z"^^xsd:dateTimeStamp.
>> >
>> >Alternatively, one might define the RDF mapping so we get something
>> >like:
>> >
>> ><https://nytimes.com><
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnytimes.com%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628081734&sdata=%2FRKjr2onvey53G0mgZmr%2BU1UHdnAkT2QNmqOBve2kow%3D&reserved=0
>> >
>> >cred:domainCreated "1994-01-18T05:00:00Z"^^xsd:dateTimeStamp
>> >although to me that feels like bad modeling.
>> >
>> >I lean towards something like:
>> >
>> >[] cred:domain "nytimes.com"; cred:created
>> >"1994-01-18T05:00:00Z"^^xsd:dateTimeStamp;
>> >
>> >   a cred:Observation, a cred:DomainAgeObservation.
>> >
>> >So, that last bit brings us back to sense 1.  I'm suggesting the object
>> >which connects a domain name and its creation time is a kind of
>> >observation, a domain name observation. We can also attach to it who
>> >did this observation, and when, and how. Then we can say "credibility
>> >signal" is a class of observations relevant to credibility assessments.
>> >The observations can then be encoded in data formats like Turtle, or
>> >CSV, or whatever.
>> >
>> >I haven't thought through exactly how the observations relate to
>> >Verifiable Credentials. VCs go much deeper into a narrower use case.
>> >There may also be some impedance mismatch with VC's crypto-centric view
>> >of the world. I'm reminded of the Knuth quote, "Beware of bugs in the
>> >above code; I have only proved it correct, not tried it." That is,
>> >crypto wont help if the institutions behind it are corrupt. CredWeb is
>> >aiming at a social notion of trustworthiness. (I'm by no means
>> >dismissing crypto, which is incredibly useful at fending off a whole
>> >range of threats. There are others it's not so useful against,
>> >however.)
>> >
>> >Hoping this made things more clear, not less,
>> >
>> >     -- Sandro
>> >
>> >
>> >Leonard
>> >
>> >From: Greg Mcverry
>> ><jgregmcverry@gmail.com><mailto:jgregmcverry@gmail.com>
>> >Date: Monday, January 20, 2020 at 2:08 PM
>> >To: Leonard Rosenthol <lrosenth@adobe.com><mailto:lrosenth@adobe.com>
>> >Cc: Sandro Hawke <sandro@w3.org><mailto:sandro@w3.org>, Credible Web CG
>> ><public-credibility@w3.org><mailto:public-credibility@w3.org>
>> >Subject: 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<mailto: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<mailto:sandro@w3.org>>
>> >Date: Monday, January 20, 2020 at 11:31 AM
>> >To: Credible Web CG
>> ><public-credibility@w3.org<mailto:public-credibility@w3.org>>
>> >Subject: CredWeb Plans, meeting tomorrow
>> >Resent-From:
>> ><public-credibility@w3.org<mailto: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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628081734&sdata=bJRVKRcowxKvXgRj1ZzloMyAZPCADiNUmGNdrVI6d0Q%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628091733&sdata=NBEAC5VTQy45aASuw%2BXeNN8NA%2FXOnB5HEhVmDe8WWpE%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628091733&sdata=sKNv%2BvQwJDaJ3aJagJgW69%2FLHWwGETwKTTA8phSKt9o%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<
>> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw3.org%2F&data=02%7C01%7Clrosenth%40adobe.com%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628101733&sdata=YwAzXUPHvdS4qbwvGADSfeVgJzBKNz3SmEMM9A6bPPo%3D&reserved=0
>> >.
>> >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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628101733&sdata=BetmqRDU3LHcsL5Y5JMh2cjX2whQvhD84a%2FeAQmCBbY%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628111727&sdata=NjJZSW8tQ2nw1h2T%2B13Wv4JYxL3jrm%2BT5l0jm2UjxAs%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628111727&sdata=i81HaxWGSHLa9v6x7MiniqVzn6zMhuECkc%2BTZ94v524%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628121723&sdata=aGOdMaXIjJRiSjCvWw5dbeQU2Ro1uWeQDh5iFKm%2BBF0%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628121723&sdata=SAnnA6Z2KBqkwA6tV32cvBEpLFOgMc9PgVCoI%2FqBUG8%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%7C65afd27a2ab94c69947908d79de9867d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637151498628131717&sdata=THJhQEUfsTGfNa0uxnvYBXSo0EymBCfj1HZaVi5TD5I%3D&reserved=0
>> >
>> >
>> >     -- Sandro
>> >
>> >
>> >--
>> >J. Gregory McVerry, PhD
>> >Assistant Professor
>> >Southern Connecticut State University
>> >twitter: jgmac1106
>>
>>
>
> --
> Thanks,
>
> Adeel Ahmad
> m: (+44) 7721724715
> e: aahmad1811@gmail.com
>
>
>
>

-- 
Thanks,

Adeel Ahmad
m: (+44) 7721724715
e: aahmad1811@gmail.com