Re: EOCred: Identify the level of a credential

Grudgingly agreed. AlignmentObject generally fails to work well as a third
party alignment (due to the awkward nature in which one has to define it as
a third party) and while it allows for new forms of alignments such as
'enables', it really conflicts with first-order alignments... which are
also awkward to define as a third party. Nothing appears to be lost.

As for saying something about the alignment itself, that doesn't really
seem necessary unless the alignment requires additional description or
justification (as it may in a third party alignment, say, marking two
degrees as equivalent as part of a report or work product).

AlignmentObject also doesn't cover conditions or other possible descriptors
of the relationship, but neither do first-order alignments. I feel like
this is all known stuff, and not stuff that we're trying to work on right
now.

If AlignmentObject had a sourceName, sourceDescription and sourceUrl, this
would be a whole different conversation. :-)

On Wed, Feb 7, 2018 at 3:23 PM, Stuart Sutton <stuartasutton@gmail.com>
wrote:

> I'd suggest forgetting about your solution "A" and focusing on "B" with
> range including DefinedTerm.
>
> It seems to me that, as characterized, we are actually talking about the
> educational/occupational level of the audience for whom the credential is
> intended or useful.
>
> I'm for an educationalLevel property even though there will be some
> categories of EducationalOccupationalCredential where the level adds
> little to what's gained from the credentialCategory (e.g., an
> EducationalOccupationalCredential of the category "Bachelor Degree" with
> the level "bachelors" isn't very enlightening; but, for many other
> categories --badge, microcredential, certificate etc.) it could be very
> useful.
>
> While the values for such a property would ideally come from controlled
> vocabularies (enumerations), for all of the reasons you note, Phil, I'd be
> very disappointed to see us pick up AlignmentObject. The first two bullets
> in your "bit" on AlignmentObject frames the reasons for it's existence per
> its development history in LRMI. BUT, since we are proposing a property of
> the sort educationLevel (audienceLevel? :-), we can scratch off bullet 1.
> Without bullet 1, AlignmentObject is nothing more than into a poor
> reflection of the pending DefinedTerm--a type more likely to garner broader
> use.
>
> Going out on a limb, possible ranges for a level property could be Text,
> URL, or DefinedTerm.
>
> Your third bullet regarding being able to say something about the
> alignment itself through property addition could be just as applicable to
> DefinedTerm as it is to AlignmentObject. No?
>
>
> Stuart
>
>
>
> On Wed, Feb 7, 2018 at 4:27 AM, Phil Barker <phil.barker@pjjk.co.uk>
> wrote:
>
>> The next use case I would like to discuss is around identifying the level
>> of an educational / occupational credential currently stated as: it should
>> be possible to search or review results of a search by specific credential
>> level, e.g. post-graduate, High school, entry, intermediate, advanced.
>>
>> To do this we need to be able to relate an educational / occupational
>> credential to a description or representation of an educational level. I
>> see two options for this:
>>
>> A. we do the same as is currently done for learning resources and courses
>> and use the educationalAlignement
>> <http://schema.org/educationalAlignment>property to point to an
>> AlignmentObject <http://schema.org/AlignmentObject> which in turn points
>> to and/or describes an educational level.
>>
>> B. we add a new property educationalLevel which could point to either an
>> AlignmentObject or directly to a DefinedTerm for the educational level.
>>
>> I'm interested in anyone's thoughts on which they would prefer.
>>
>>
>> =A bit of background to the AlignmentObject.=
>>
>> - the educationalAlignment / AligmentObject pairing is useful when you
>> don't want to pre-define and thus limit types of alignments involved by
>> having a few properties for specific alignments (that's at the root of why
>> LRMI introduced it, here we have a specific alignment type we know we want.)
>>
>> - the AlignmentObject is useful when the thing to which you are aligning
>> is not properly defined a a firstclass schema.org object; it allows you
>> to refer to it by description
>>
>> - the AlignmentObject is useful when you want to say things about the
>> alignment itself (e.g. describe who asserts the alignment is true and how
>> they came to this judgement) though this ability is under developed and to
>> my knowledge not used
>>
>> - research <https://dl.acm.org/citation.cfm?id=3054160>[*] into LRMI
>> schema.org markup in the wild suggests that the AlignmentObject (and
>> relatively more complex / abstract approaches in general) are used less
>> frequently than simpler property - value [literal] relationships.
>>
>> - the Open Badges spec uses an alignment property to point from a badge
>> class to an AlignmentObject representing objectives or educational
>> standards (which is slightly different to this use case, though we several
>> use cases for aligning to competencies)
>>
>>
>> Please let me know your thoughts.
>>
>> Phil
>>
>>
>> * open access copy of that paper at https://blogs.pjjk.net/phil/co
>> nfpaper/analysing-improving-embedded-markup-learning-resources-web/
>>
>>
>> --
>>
>> 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
>
>
>