Re: EOCred: Identifying subtypes of credential

Alex, were you asking about Phil's example?

On Wed, Jan 17, 2018 at 9:24 AM, Alex Jackl <alex@bardicsystems.com> wrote:

> Not to ask a stupid question but, Stuart, in the example you provided I
> don't see any URI or place to put a unique identifier in.   Can you point
> to how that would be handled?
>
> I probably just missed something!
>
> Alexander Jackl
> CEO & President, Bardic Systems, Inc.
> alex@bardicsystems.com
> M: 508.395.2836 <(508)%20395-2836>
> O: 401.384.0566 <(401)%20384-0566>
> F: 617.812.6020 <(617)%20812-6020>
> http://bardicsystems.com
>
> On Wed, Jan 17, 2018 at 9:04 AM, Stuart Sutton <stuartasutton@gmail.com>
> wrote:
>
>> Phil, I agree that a credentialType property is needed. I think that
>> having the range include both Text *and* URL to allow identification by
>> URI where available and text where not is appropriate. You are right that
>> CTDL defines subclasses of it's Credential class
>> <http://purl.org/ctdl/terms/Credential> and that no single enumeration
>> will handle the breadth of the range (and internationalization issues);
>> but, where such enumeration(s) exist, my sense is that they should be used.
>> The CTDL defines a credentialType
>> <http://purl.org/ctdl/terms/credentialType> property that is intended to
>> be used wherever reference to a member of the Credential class is needed.
>> It's range now enumerates the CTDL subclasses; but should likely reference
>> more inclusively the Credential class.
>>
>> As for use of TermDefinition to identify/define members of such
>> enumerations, I hope that it gets approved in a timely manner and that we
>> are not forced to even contemplate use of AlignmentObject (ugh...don't get
>> me started).
>>
>> Stuart
>>
>> On Wed, Jan 17, 2018 at 3:20 AM, 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
>>>
>>
>>
>>
>> --
>> Stuart A. Sutton, Metadata Consultant
>> Associate Professor Emeritus, University of Washington
>>    Information School
>> Email: stuartasutton@gmail.com
>> Skype: sasutton
>>
>>
>>
>


-- 
Stuart A. Sutton, Metadata Consultant
Associate Professor Emeritus, University of Washington
   Information School
Email: stuartasutton@gmail.com
Skype: sasutton