Re: EOCred: Identifying subtypes of credential

I have created a wiki page describing this proposal 
<https://www.w3.org/community/eocred-schema/wiki/Catagorize_credential_by_type>, 
including a couple of examples, and reflecting the input of the 
discussion so far.

One example uses a local but specific credential subtype with no RDF 
representation to link to, and so the DefinedTerm relies on text values 
only. The other example uses the CTDL:Certification class, and I have 
attempted to show how additionalType etc. can be used as well as 
credentialType.

If anyone with an eye for detail would like to check these, that would 
be welcome. (Please look out for me  using TermDefinition in error for 
DefinedTerm, and check the use of additional types.)

Let me know if you wish to discuss further.

Regards, Phil

[wiki page] 
https://www.w3.org/community/eocred-schema/wiki/Catagorize_credential_by_type



On 17/01/18 11:20, Phil Barker wrote:
>
> Hello again, moving on to the next requirement for describing 
> Educational and Occupational Credentials in schema.org: I suggest we 
> look at how to identify the subtypes of these credentials.
>
> The use case for this 
> <https://www.w3.org/community/eocred-schema/wiki/Use_Cases#Identify_subtypes_of_credential> 
> gives examples of "degree" "certificate" "badge". I know there are 
> about 20 others from the Credential Engines' CTDL 
> <http://credreg.net/ctdl/handbook#creds>. Most countries will have 
> their own types of EO Credential, for example in Scotland we have  
> National Qualifications, HNDs, HNCs, SVQs, IVAs, PDAs, DipHEs, CertHEs 
> and many more. Other countries will be similar. Furthermore, the types 
> of qualification on offer changes over time.
>
> In short, the number of types is we need to consider is vast and 
> varied. So, while CTDL has subclasses of its Credential class for each 
> of its distinct types, that is not a practical solution for wider use. 
> Even if we could reduce the number and variety of types, I think it 
> would add too many subclasses to the schema.org hierarchy, given that 
> most of the subtypes would have no unique properties.
>
> The alternative is for EducationalOccupationalCredential to have a 
> property which records the type of credential. With a nod to Richard's 
> point that much of what we do is applicable to generic credentials, I 
> propose we call this credentialType.
>
> The basic range for credentialType would be text, and I think we 
> should explicitly allow this. We could stop here.
>
> In an ideal world there would be controlled vocabulary for naming the 
> credentialTypes. However, I a single controlled vocabulary of all the 
> precise types is not feasible, and I think that producing a vocabulary 
> that classifies these types into categories like "certificate" would 
> be very difficult and the results would be very imprecise. We should, 
> however try to facilitate the use of local controlled vocabularies. 
> This is where we reach the edge of what currently possible in schema.org.
>
> Options for facilitating the use of local controlled vocabularies of 
> credential type:
>
> 1, allow a URL to link to a controlled value / external enumeration.
>
> 2, allow alignmentObjects to provide information about the 
> credentialType as if credential types were educational frameworks
>
> 3, use the developing schema.org type that is currently called 
> CategoryCode <http://pending.schema.org/CategoryCode>, but which is 
> proposed to be changed to TermDefinition
> <https://github.com/schemaorg/schemaorg/issues/1775>
>
> In my view: 1 is too vague (who knows what will be at the end of the 
> URL), 2 stretches the alignmentObject somewhat, and 3 is the best 
> option for the long run. An example using option 3 would look 
> something like:
>
> {
>   "@type": "EducationalOccupationalCredential",
>   "name" : "HNC Facilities Management",
>   "credentialType": {
>     "@type" : "TermDefinition",
>     "name" : "Higher National Certificate",
>     "termCode" : "HNC",
>     "inDefinedTermSet" : "SQA Qualifications" //should be a URL or 
> DefinedTermSet object
>   }
> }
>
> What do you think? Too complicated, maybe? Am I overthinking the 
> problem? Are there enough well-constructed sets of terms describing 
> credential types for it to be worth trying to accommodate anything 
> other than text values?
>
> 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
>

-- 

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