Re: EOCred: recognition of credential

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>
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>
> 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
>> 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>
>> 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.
>>>
>>> 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 statements. If I use 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 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
>>> 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 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, 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
>>> *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
>>
>
>