Re: EOCred: Addressing requirements from use cases

There is a lot in this that is worth thinking about. Questions like 
these will surface assumptions about what it is we are defining.

On 09/01/18 16:10, Richard Wallis wrote:
> In principle creating an *EducationalOccupationalCredent**ial* type 
> and making it a subtype of *CreativeWork* make sense to me.  This is a 
> good start. However the following practical thoughts come to mind:
>
>   * Just looking at the name
>     *EducationalOccupationalCredent**ial*makes me think that it should
>     have a basic super-type of *Credential* that is not tied to the
>     Educational / Occupational domains.  I can already anticipate the
>     questions about marking up some form of general qualification,
>     measure of achievement, recognised membership level, or
>     attendance, that the developer does not consider either
>     educational or occupational.
>
Yes, agreed. However, I do not know what the properties of a 
non-educational/occupational credential will be. We could speculate that 
some of our use cases are general beyond the education and workplace 
development world, but I am not sure that would be a good use of our 
expertise. Anyway, if a generic Credential object type is introduced at 
some time in the future, before or after this project has finished, it 
should be simple enough to make EducationalOccupationalCredential a 
child of it. *So I would be happy to note this and pass on. Is that OK?*

>   * In practice “/properties like educationalAlignment, audience,
>     offers, provider, hasPart, datePublished, dateModified, expires,
>     creator (and possibly others) will be useful in describing
>     EducationalOccupationalCredentials./” Is not sufficient reason on
>     its own for minting yet another subtype of CreativeWork.  Do we
>     believe such a thing is a type of Creative Work?
>
Agreed. I skipped over the justification that it is logical to consider 
EducationalOccupationalCredential a subtype of CreativeWork. My 
reasoning is that EO Credentials don't exist unless someone creates 
them. Someone has to design them, i.e. specify the competences or other 
eligibility criteria. Once a credential has been described, i.e. given a 
name, a description, and the bundle of eligibility criteria has been 
specified, then you have Creative Work, taking wikipedia's definition "a 
manifestation of creative effort".

One useful distinction is that between an 
EducationalOccupationalCredential which is offered by some 
credentialling organization, and the claim by an individual to have such 
a credential.  A well-established parallel for this is OpenBadges 
<https://openbadges.org/>, which have a Badge class 
<https://www.imsglobal.org/sites/default/files/Badges/OBv2p0/index.html#BadgeClass> 
and an Assertion 
<https://www.imsglobal.org/sites/default/files/Badges/OBv2p0/index.html#Assertion>. 
The Badge Class is "a collection of information about the accomplishment 
recognized by the Open Badge". Again, "a collection of information" 
sounds like a CreativeWork to me. *Please comment if you are not happy 
that **EducationalOccupationalCredential is similar to Badge Class 
rather Assertion or something else.*

I think it is relevant that the Credential Registry's CTDL defines a 
copyrightHolder property for a credential 
http://www.credreg.net/ctdl/terms#copyrightHolder  (I know it is 
crossing domains a bit, but in my mind copyright implies a creative 
work)*I would be really interested in examples of what people claim 
copyright over with respect to credentials.

*
>
>  *
>     I had a recent proposal for a new subtype of CreativeWork, using
>     similar justification, knocked back in the Schema.org Github in
>     this way:
>
>         “/No, we really can//’t make TouristTrip a subclass of
>         CreativeWork … that //would be way way too much of a hack.
>         ////Lets add more domain/ranges to the relevant properties.”/
>
>
>     I am not saying we would get the same response but we need good
>     justification for such a proposal.
>
>
Yup, I can certainly see an argument that it would be possible to to 
define an EOCredentials as a subtype of  Intangible and to extend the 
domain of the relevant properties. I think building classes by 
composition has some advantages over inheritance. But I am pretty sure 
that some point we would want a property along the lines "documentation" 
of the credential pointing to the official description on a website, and 
I think that would get confusing.

Thanks for raising this Richard, you're absolutely right that it needs 
discussion.

Phil
-- 

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: 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