Re: EOCred: Identifying subtypes of credential

Thank you Richard, I had forgotten the latest iteration, to keep 
CategoryCode under TermDefinition. I think TermDefinition is the more 
generally appropriate type for what we are discussing.

Phil


On 17/01/18 17:32, Richard Wallis wrote:
> 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 
> <mailto:phil.barker@pjjk.co.uk>> wrote:
>
>     Hello again, moving on to the next requirement for describing
>     Educational and Occupational Credentials in schema.org
>     <http://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
>     <http://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 <http://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 <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>
>
>     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