Re: EOCred: recognition of credential

In terms of Academic Degrees, employers would likely find a
"workingTowards" Degree to be useful for hiring: current and continuing
students may have the freshest information just ripe for application to
solving real problems and the most enthusiasm.

AFAIU, such status could also be verified with W3C Verifiable Claims:
https://www.w3.org/TR/verifiable-claims-use-cases/
https://www.w3.org/TR/verifiable-claims-data-model/

On Tuesday, May 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:

>
>
> On Tuesday, May 22, 2018, Phil Barker <phil.barker@pjjk.co.uk> wrote:
>
>> Thank you Nate. I understand your reluctance to accept unverified
>> statements of recognition for your use cases and appreciate your agreement
>> not to block their use for other cases (where I think verification can be
>> by other means).
>>
>> I don't think here is the right place to go into details of how our
>> proposal would work with any future development of verifiable endorsements,
>> but I think there are a couple of options: either using a pattern similar
>> to that shown <http://blog.schema.org/2014/06/introducing-role.html> by
>> Role <http://schema.org/Role> where an intermediate schema.org type can
>> provide additional information about a relationship (the AlignmentObject
>> does something like this too), or by creating new verifiedRecognition
>> property. I am confident therefore that having recognizedBy as a property
>> won't prejudice any future efforts to verify such a claim.
>>
> I originally had Credential and CredentialInstance (with issuer and issuee
> properties). It was then proposed that a ConferAction schema.org/Action
> should be created in order to reify the relation.
>
> AFAIU, the scope of this WG specifically excluded linking between
> individuals and instances of credentials.
>
> W3C Verifiable claims has a multi-step workflow which is more correct than
> adding ConferAction and RevokeAction someday, IIUC.
>
> Actions: Issue, Assert, Verify, Store/Move, Retrieve, Revoke
>
> Most existing claims (such as on a social network profile or an resume)
> are not yet verifiable: we can accept them at face value only and there may
> never be any way to issue cryptographically-signed verifications from
> entities capable of securing a private/public keypair.
>
> While existing professional and academic social networks do allow
> unverified claims regarding Credentials (and any other fact but email
> address), we might shouldn't even make it possible to express such a
> relation without e.g. W3C Verifiable Claims.
>
>> Regards, Phil.
>>
>> On 22/05/18 15:49, Nate Otto wrote:
>>
>> For me, the verifiable endorsements are the only type of recognition that
>> I would trust. I won't block the inclusion of recognizedBy, but structuring
>> the relationship as RecognizedEntity.recognizedBy -> RecognizingEntity
>> doesn't allow for the relationship to flow through a specific verifiable
>> record describing that recognition. I think the
>> RecognizedEntity.endorsements -> Endorsement -> Endorsement.issuer ->
>> RecognizingEntity allows us to describe the scope or purpose the credential
>> or other entity is recognized for.
>>
>> Nate Otto
>> Director, Open Badges, Concentric Sky
>> concentricsky.com
>> he/him/his
>>
>>
>> --
>>
>> 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
>>
>