Re: EOCred: Identifying subtypes of credential

Hi Phil,

I agree that creating individual Schema.org subtypes for each credential is
both undesirable and impractical.  From the points of view of: who would do
it; the high possibility of not capturing them all; the acceptability of
such a solution to the Schema.org community.

The use of a credentialType property seems to be a good alternative.

A basic range of Text would allow at least basic description of credential
type to be provided.

I also agree a single controlled vocabulary of all the precise types is not
feasible, however like many definition options utilised on the Web there
may well be several sources that describe/Identify these from Wikidata,
through sources using CDTL subclass, to local controlled vocabularies.
This is no different, in Schema.org terms, to using a Wikidata URI
to identify the *author* of a *Book*.

As to your 3 options my comments are:


   1. *allow a URL to link to a controlled value / external enumeration.*
   It is a default case that any Schema.org property can take a URL as a
   value.  (Note the *author* property mentioned above does not include URL
   in its range). However, it may be worth explicitly including URL in the
   range to specifically indicate the availability of this approach.

   2. *allow alignmentObjects to provide information about the
   credentialType as if credential types were educational frameworks.*
   This does stretch alignmentObject somewhat, and seems over complex to me.

   3. *Use the developing schema.org <http://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>.*
   The proposal has evolved somewhat and now is for *CategoryCode* to
   become a subtype of *TermDefinition*.   I am hoping that this proposal
   will be part of the next release of Schema.org.
   For locally defined controlled vocabularies I would definite recommend
   such an approach.  I would also encourage other [non local] sources of such
   definitions to use the same approach for their data publishing to make them
   more generically useful.

~Richard.

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 17 January 2018 at 11:20, Phil Barker <phil.barker@pjjk.co.uk> 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
>