Re: EOCred: Identifying subtypes of credential

Following the discussions here, and a comment from Stuart I have made 
some changes to proposal on the wiki 
<https://www.w3.org/community/eocred-schema/wiki/Catagorize_credential_by_type> 
for how we identify what kind of credential we are talking about.

I have *renamed the property* proposed to credentialCategory & tweaked 
the definition. I hope this is enough to keep Fritz Ray happy 
('credentialCategory is disarming to presumptuous software folk like me 
who "know what type and class means" and have a tendency not to read 
descriptions'), and still have the support of those who supported the 
original proposal.

I have *tidied up the examples* to resolve an issue Stuart pointed out 
arising from the use of identifiers for entity type, resource and 
schema:url in the examples (I hope nothing now points to itself as its 
own url).

Phil

wiki page: 
https://www.w3.org/community/eocred-schema/wiki/Catagorize_credential_by_type#Draft_code_for_schema.org

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