Re: EOCred: Identifying subtypes of credential

Sure. I posted my work here.

https://github.com/Lomilar/schemaorg/blob/8dd7f243103c1e997e22189b56f453d599b74762/data/ext/pending/issue-1779.rdfa

Reading the website, an HNC appears to be a certificate with a couple extra
properties.

It could be the case, I have no honest idea, that the Scottish
Qualifications Authority may want to own the terminal definition of HNCs,
but use existing standards for the majority of the definition. I went ahead
and made that assumption, and had an HNC (not a schema.org class) be a
subclass of a EOCertificate, which is a schema.org class and a subclass of
EOCredential. Liberties have been taken, this is purely for illustrative
purposes!

I've also defined a couple of properties that appear to be significant for
HNCs, that they have both credit point and credit hours requirements. The
credit points seem to be distinct from the credit hours. The credit hours
also appear to have assumptions behind them (40 hours of guided learning,
40 hours of self-directed learning) so I specified them as
'hnuCreditsRequired' and the credit points as 'scqfCreditPointsRequired'.
This is by no means exhaustive and it may not be accurate, just a quick
interpretation of the material. hnuCreditsRequired could be added to other
credentials that observe them.

So now HNCs are their own class, but are also a subclass of EOCs, which
means that a more specific search (for HNCs) should bring them up, and a
more general search (for EOCs) should also bring them up, presuming the
search engine can interpret a hierarchical class structure and go fetch
schemas and do all the things that we expect they should be able to do.

-----

I concede that this is a fairly 'puritan' approach to typing, and that it
presumes a certain complexity of the technology used to interpret these
objects (namely to interpret class structures inside and outside schema.org).
It also presumes a willingness for organizations with particular
definitions to extend schema objects with those particularities. If
publishing schemas were as simple as publishing data, this wouldn't be a
problem, but alas.

If this argument fails to convince, perhaps a rename to 'credentialTerm' to
get it away from the connotations of type? I really want some property of
Thing like "alsoCalledA" that allows one to provide a preferred name for
the class of thing it is (commonly found as options in the description, see
CreativeWork's description, for instance).


On Wed, Jan 24, 2018 at 5:24 AM, Phil Barker <phil.barker@pjjk.co.uk> wrote:

> Hello Fritz,
> On 23/01/18 22:44, Fritz Ray wrote:
>
> Hi Phil,
>
> I appreciate the pragmatic approach, and I don't disagree with anything
> you have said.
>
> Where I don't want to get is where we're at with schema.org/CreativeWork
> with "learningResourceType", defined as being able to be things like
> "presentation" or "handout" -- These are more than just labels, these are
> indicators of what properties the resource has, and violate the basis of
> object oriented structures, where 'is a' relationships are defined by
> subclasses and 'has a' relationships are described in properties.
>
> I don't want to get too involved in wider-scale modelling within
> schema.org (at least not here), but learningResourceType is quite an old
> bit of schema.org, which predates any concepts like DefinedTerm. I think
> that as soon as DefinedTerm is secure in schema.org we will be wanting to
> add it to the expected range of learningResourceType. There similar issues
> with the number different schemes for learningResourceType (and throw in
> some vastly different conceptualization of 'type').
>
>
> Consider which sounds more clear:
> Presentation is a creative work, Handout is a creative work.
> Creative work has a learning resource type of Presentation.
>
> I have no problem with people doing both. There will always be some types
> which aren't represented in the schema.org hierarchy, and for which there
> is no suitable URI linking to some other vocabulary: how will these be
> represented if there is no learningResourceType?
>
> What happens is that at some point down the line, these differences matter
> enough to want to functionally distinguish between, say, a Credential and a
> Qualification, or in the above, a presentation and a handout. Presentation
> (as a creative work) may have a slide count, but handouts don't. Do I add a
> slide count property to CreativeWork? What happens when I create
> Presentation as a subtype of CreativeWork, and what does that mean for apps?
>
> You may find apps consuming schema.org have to do more work (in this case
> looking at learningResourceType and the schema.org class), while it is
> easier for publishers of data to publish about resources for which there is
> no specific schema.org class.
>
>
> This has exactly happened. PresentationDigitalDocument is a type of
> DigitalDocument is a type of CreativeWork, and http://schema.org/subEvent
> states that a Presentation is probably best subtyped from Event.
>
> [aside: note the problem of Presentation being a CreativeWork which is
> presented (e.g. a powerpoint deck) or the event at which it is presented]
>
>
> So, do I create a CreativeWork with learning resource type Presentation,
> or do I create a PresentationDigitalDocument? Do I redundantly label the
> PresentationDigitalDocument with learning resource type: Presentation?
>
> Personally, I would create PresentationDigitalDocument with redundant
> resource type.
>
> I get wanting to allow people to describe things in their own way, but
> subtypes described as properties create enormous problems, and just as
> http://schema.org/Course doesn't allow itself to be labelled with Course,
> Class, Lecture, Workshop, Lab or any of the other variants (IgniteTalk,
> MOOC),
>
> Modelling again: They may be considered learning resource types, or (my
> preference) the same course could be presented as an online or a face to
> face class. CourseInstance <http://schema.org/CourseInstance> does have
> courseMode <http://schema.org/courseMode> property for exactly this.
>
> I don't think we should either.
>
> So, are you saying that we should strike the use case of wanting to
> provide information about subtypes of credential? If not, how would you
> encode SQA's HNCs <https://www.sqa.org.uk/sqa/168.2432.html> as a subtype
> of credential?
>
> Especially in light that many of these different types of credentials will
> have additional properties, and will warrant subtypes. Degrees occur at
> masters, bachelors, associates levels, but qualifications don't.
>
> In the UK, degrees are commonly called qualifications. See also first
> sentence of wikipedia:Academic degree
> <https://en.wikipedia.org/wiki/Academic_degree>. So are HNCs for that
> matter. Did I mention that agreeing on a typology for global use would be
> difficult?
>
> Specific classes of teaching certificates may only qualify at particular
> grade levels, and that's something you want in the subtype but not in EOC.
>
> I think the specifics of that goes beyond our current use cases. We do
> have a use case around finding jobs / occupations that match a credential
> (or vice versa), so if Primary School Teacher is an occupation distinct
> from Teacher the specific EOCredential required for that should be findable.
>
> Perhaps I am still not getting your proposal. If so, could you show some
> specific examples or how it would work, say with SQA HNCs?
>
> Phil
>
>
>
> On Thu, Jan 18, 2018 at 3:42 AM, Phil Barker <phil.barker@pjjk.co.uk>
> wrote:
>
>> Hello Fritz, I don't disagree with many of the points you raise, I think
>> you are (mostly) factually correct, but I do disagree with your conclusion.
>> This based on pragmatic judgement of what we can create and maintain, what
>> we can expect to be accepted as additions to schema.org, and what we can
>> expect providers of data to do.
>>
>> additionalType is a possibility, worth discussing separately. My concern
>> is that it lacks support for text values. You and I both wish that more
>> data were provided as URIs, but the reality is that there are no URIs for
>> many of the credential subtypes. We have to support text values.
>>
>> Adding subtypes of EducationalOccupationalCredential to schema.org for
>> all the specific types of credential is a non-starter for me. There would
>> be thousands. We couldn't hope to collect them all, and schema.org would
>> not accept so many.
>>
>> Creating a typology along the lines of what is in CTDL, I also do not
>> think would work. I think 20 or so sub types would be too many for schema.
>> Doing anything meaningful by way of a global classification of credential
>> types is not a task I would want to take on (I've seen how difficult it is
>> just within Europe). Some examples of the difficulties can be seen in
>> trying to fit European credentials to CTDL. The distinction between Diploma
>> and Certificate in the UK's HND and HNC are not well conveyed by the
>> definitions for ceterms:Diploma and ceterms:Certificate, and losing
>> distinctions like this would be detrimental to fulfilling the use case. I
>> can also imagine all sorts of errors in data provision arising from
>> instances like the old-style German Diplom and Spanish Licenciatura
>> (comparable to Masters degrees, not diploma or licence).
>>
>> I do not agree that pointing to an externally defined term discourages
>> subtyping. If a DefinedTerm is part of a DefinedTermSet, relationships
>> between terms may be defined using vocabularies such as SKOS. However, the
>> harsh reality in which we have to operate is that they are more likely to
>> be defined in pdfs. Sorry.
>>
>> Finally, remember the use case is to allow people to search for a
>> specific type of credential. For example, "where can I find information
>> about PGCEs?". credentialType="PGCE" would suffice in many cases.
>>
>> Phil
>>
>> On 17/01/18 18:07, Fritz Ray wrote:
>>
>> I want to say that Stuart and I have already had this discussion, but:
>>
>> I don't think credentialType is needed.
>>
>> Adding credentialType conflicts with the intent of the object's type.
>> Remember, type is just a field as well.
>>
>> Schema.org/Thing also has http://schema.org/additionalType to permit the
>> adding of additional (specific, not defined here) type data to any object.
>>
>> http://schema.org/Action is a good example of where a lot of subTypes
>> are added to a base class without necessarily adding properties (though
>> some do!), so we also have precident there.
>>
>> There's lots of established avenues that allow for subtyping. On the
>> other hand, there are also several instances of additional type being
>> specifically identified, usually paired with a fixed taxonomy of types
>> (ActionStatusType, BoardingPolicyType, BusinessEntityType,
>> EventStatusType). I also believe these instances aren't in the spirit of
>> schema.org.
>>
>> Type properties like credentialType prevent additional subtyping and
>> encourage "text" descriptions (see AlignmentObject's AlignmentType) where
>> it should really be URLs so that interpretations can be distinguished and
>> separate.
>>
>> Type properties also discourage additional subtyping and do not prevent a
>> means of structuring dependent subtypes. Is an IVA credential (from the
>> example above) a type of SVQ credential? Without an additional structured
>> ontology to point at, it is difficult to know.
>>
>> What additional properties does a specific type of credential confer? For
>> instance, a military MOS credential may have a securityClassificationLevel.
>> Do we need to add those properties to the base class? (With credentialType,
>> maybe, with subtypes, certainly not.)
>>
>> 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
>>>
>>>
>>>
>>
>> --
>>
>> 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
>