Re: EOCred: recognition of credential

OK, thanks folks. On the basis of this feedback from Stuart and Fritz 
I'll put recognizedBy back into the proposed changes. We can revisit 
that if anyone expresses continued misgivings between now and submitting 
the proposal.

Phil


On 15/05/18 16:43, Fritz Ray wrote:
> I agree that the perceived currency depends, but my main gripe was 
> that accreditation is more than a better recognition, it carries with 
> it a network effect that recognition doesn't. They are functionally 
> different. In my mind, Recognition states that my organization accepts 
> this, Accreditation states that those who recognize my organization 
> (must? have agreed to?) accept this.
>
> We can proceed at this point with recognizedBy until there's further 
> consensus on the mechanics.
>
> On trust and verifiability, I don't have much to say that isn't 
> already being covered by Verifiable Claims, JSON Web Signatures and 
> http://schema.org/EndorseAction.
>
>
> On Tue, May 15, 2018 at 8:25 AM Stuart Sutton <stuartasutton@gmail.com 
> <mailto:stuartasutton@gmail.com>> wrote:
>
>     Hmmm. I didn't read either Fritz or Nate's comments as being
>     negative in terms of recognizedBy. Nate and Fritz, what do you
>     say? Can we proceed at this point with recognizedBy? Fritz in your
>     comments you agreed with a subproperty relationship between
>     recognizedBy and a possible future accreditedBy. The currency one
>     places in these two related notions is relative. While
>     accreditation is certainly important, there are some (like one
>     employer) who might well see a credential recognizedBy another
>     employer of note as more important than accreditation. So, like so
>     many thing, perceived currency depends.
>
>     On Tue, May 15, 2018 at 7:42 AM, Phil Barker
>     <phil.barker@pjjk.co.uk <mailto:phil.barker@pjjk.co.uk>> wrote:
>
>         Thanks Stuart,
>
>         The sense I got arose from comments from Fritz
>         <https://lists.w3.org/Archives/Public/public-eocred-schema/2018Apr/0004.html>
>         [1] about accreditation being more important than recognition,
>         and from Nate Otto
>         <https://lists.w3.org/Archives/Public/public-eocred-schema/2018May/0000.html>
>         [2] about trust and verfiability.  I am not sure how widely
>         these concerns are shared or whether my replies [3
>         <https://lists.w3.org/Archives/Public/public-eocred-schema/2018May/0001.html>]
>         and [4
>         <https://lists.w3.org/Archives/Public/public-eocred-schema/2018Apr/0005.html>]
>         addressed them satisfactorily.
>
>         If we can clarify those points one way or the other that would
>         be great.
>
>         Phil
>
>         1.
>         https://lists.w3.org/Archives/Public/public-eocred-schema/2018Apr/0004.html
>
>         2.
>         https://lists.w3.org/Archives/Public/public-eocred-schema/2018May/0000.html
>         3.
>         https://lists.w3.org/Archives/Public/public-eocred-schema/2018May/0001.html
>         4.
>         https://lists.w3.org/Archives/Public/public-eocred-schema/2018Apr/0005.html
>
>
>         On 15/05/18 14:01, Stuart Sutton wrote:
>>         Phil, I am not so certain that there isn't consensus around
>>         the original proposal for a recognizedBy property with a
>>         domain of EducationalOccupationalCredential and a range of
>>         Organization [1]. Just because there is a likelihood that
>>         such claims by the owner of a credential might well need to
>>         be verified for maximum ease and utility, that doesn't negate
>>         the need for a credential provider to be able to make the
>>         claim. And, as you rightly note, a new recognizedBy property
>>         would be only one of many claims made through other
>>         schema.org <http://schema.org> properties that could benefit
>>         from being verifiable. So while agreeing that there needs to
>>         be a more general mechanism for handling verifiable claims,
>>         first, we need to be able to make such claims and second, its
>>         an issue to be solved beyond this property.
>>
>>         Since I have heard nothing in opposition to a recognizedBy
>>         property itself, I'd say you should, at least for now, call
>>         going once, going twice, included. We can always revisit as
>>         the full package of properties for a useful
>>         EducationalOccupationalCredential comes into view.
>>
>>         [1]
>>         https://www.w3.org/community/eocred-schema/wiki/Show_organizations_that_recognize_an_educational_occupational_credential
>>
>>         On Tue, May 15, 2018 at 2:36 AM, Phil Barker
>>         <phil.barker@pjjk.co.uk <mailto:phil.barker@pjjk.co.uk>> wrote:
>>
>>             OK, I am getting the sense that there isn't a
>>             particularly strong consensus around how to deal with
>>             this issue, so I shall park it for now. We can reconsider
>>             parked issues when we review the proposal we put forward
>>             to schema.org <http://schema.org>.
>>
>>             Phil
>>
>>
>>             On 03/05/18 11:01, Phil Barker wrote:
>>>
>>>             Thanks Nate, that's interesting about 'endorsements'
>>>             being claims that could be verified. I agree that in
>>>             many use case it will important to provide evidence or
>>>             proof of authority for statements like 'This
>>>             EOCredential is recognised by X'. (By the way one
>>>             potential point of confusion if a driving licence is a
>>>             credential: in the UK an endorsement
>>>             <https://www.gov.uk/penalty-points-endorsements> on a
>>>             driving licence indicates the driver has been penalized
>>>             for some infringement. Get enough endorsements and
>>>             you'll be disqualified from driving.)
>>>
>>>             As a matter of fact I think this issue of verifiability
>>>             is pertains to many schema.org <http://schema.org>
>>>             statements. If I use schema.org <http://schema.org> to
>>>             say that I work for PJJK Limited, would you believe me?
>>>             Or that my name is Phil Barker? Or that I wrote a
>>>             certain scientific paper, and that I hold the copyright
>>>             for it? So I would say that schema.org
>>>             <http://schema.org> properties like worksFor
>>>             <http://schema.org/worksFor>, name
>>>             <http://schema.org/name>, author
>>>             <http://schema.org/author>, and in fact pretty much
>>>             every schema.org <http://schema.org> property, could be
>>>             treated as relating to a claim that requires
>>>             verification for some use-cases. So I think that a
>>>             mechanism for verifiable claims made as statements using
>>>             schema.org <http://schema.org> should be a general one
>>>             that works across all properties (have a look at how
>>>             Role <http://schema.org/Role> provides more information
>>>             about a relationship or property for one way of
>>>             addressing a similar problem).
>>>
>>>             I agree that providing a mechanism for verifying claims
>>>             made on the web is an important thing to do, and I agree
>>>             that it would be useful to do this for claims encoded in
>>>             schema.org <http://schema.org>, but (as you know) it is
>>>             a general (and difficult) problem.
>>>
>>>             I don't think it is the problem we are trying to solve
>>>             with schema.org <http://schema.org> /here/.
>>>
>>>             I would state our use case as this:
>>>
>>>                 A website / email / other text includes the
>>>                 [unverified] statement that an educational
>>>                 occupational credential is recognized by some
>>>                 relevant organization. We wish to make that
>>>                 statement more easily processed by computers through
>>>                 semantic markup.
>>>
>>>             Extension of use case:
>>>
>>>                 The same mark up may be used to provide similar
>>>                 information as structured data independently of text
>>>                 on a web page or other medium.
>>>
>>>             Does that seem like a reasonable use case to address? Is
>>>             it useful to make unverified claims about recognition of
>>>             credentials machine readable?
>>>
>>>             If so, is there any improvement to the definition of the
>>>             recognizedBy property that would help clarify that the
>>>             claim to recognition may require further verification?
>>>
>>>             Regards, Phil
>>>
>>>             On 02/05/18 21:14, Nate Otto wrote:
>>>>             For some extra context/flavor:
>>>>
>>>>             In Open Badges, we use the W3C Verifiable Credentials
>>>>             vocab/methodology to enable 3rd parties to create
>>>>             Endorsements that describe their recognition of a
>>>>             particular defined Credential. This is still early
>>>>             days, but in the current version of the OB vocabulary,
>>>>             there is a property that allows publishers to identify
>>>>             the "endorsements" that have been awarded to the
>>>>             Credential (or to the Issuer, or to the awarded
>>>>             instance of the credential).
>>>>
>>>>             Because each endorsement is separately verifiable, the
>>>>             publisher's word doesn't need to be trusted when they
>>>>             describe organizations/individuals who recognize the
>>>>             badge. This means that the relationship is actually
>>>>             between the (Credential -> Endorsement -> Issuer of the
>>>>             Endorsement), not directly (Credential -> Issuer of the
>>>>             Endorsement)
>>>>
>>>>             If we add in a recognizedBy feature in the vocabulary,
>>>>             it might be useful to define use cases for how this
>>>>             data is published (who is publishing it, where, and for
>>>>             what audience?) and when/why that published data should
>>>>             be trusted by consumers. This might yield additional
>>>>             properties we might need in order to support those use
>>>>             cases, or we might want to go the Open Badges route of
>>>>             modeling the Endorsement of the credential itself as an
>>>>             intermediate relationship.
>>>>
>>>>             Nate
>>>>
>>>>
>>>
>>>             -- 
>>>
>>>             Phil Barker <http://people.pjjk.net/phil>.
>>>             http://people.pjjk.net/phil
>>>             PJJK Limited <https://www.pjjk.co.uk>: technology to
>>>             enhance learning; information systems for education.
>>>             CETIS LLP <https://www.cetis.org.uk>: a cooperative
>>>             consultancy for innovation in education technology.
>>>
>>>             PJJK Limited is registered in Scotland as a private
>>>             limited company, number SC569282.
>>>             CETIS is a co-operative limited liability partnership,
>>>             registered in England number OC399090
>>>
>>
>>             -- 
>>
>>             Phil Barker <http://people.pjjk.net/phil>.
>>             http://people.pjjk.net/phil
>>             PJJK Limited <https://www.pjjk.co.uk>: technology to
>>             enhance learning; information systems for education.
>>             CETIS LLP <https://www.cetis.org.uk>: a cooperative
>>             consultancy for innovation in education technology.
>>
>>             PJJK Limited is registered in Scotland as a private
>>             limited company, number SC569282.
>>             CETIS is a co-operative limited liability partnership,
>>             registered in England number OC399090
>>
>>
>
>         -- 
>
>         Phil Barker <http://people.pjjk.net/phil>.
>         http://people.pjjk.net/phil
>         PJJK Limited <https://www.pjjk.co.uk>: technology to enhance
>         learning; information systems for education.
>         CETIS LLP <https://www.cetis.org.uk>: a cooperative
>         consultancy for innovation in education technology.
>
>         PJJK Limited is registered in Scotland as a private limited
>         company, number SC569282.
>         CETIS is a co-operative limited liability partnership,
>         registered in England number OC399090
>
>

-- 

Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil
PJJK Limited <https://www.pjjk.co.uk>: technology to enhance learning; 
information systems for education.
CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for 
innovation in education technology.

PJJK Limited is registered in Scotland as a private limited company, 
number SC569282.
CETIS is a co-operative limited liability partnership, registered in 
England number OC399090

Received on Friday, 18 May 2018 08:22:07 UTC