Re: EOCred: Identify the level of a credential

The technical source is defined by the CreativeWork that holds the
AlignmentObject.

An AlignmentObject is, and let me know if I'm wrong here, a "complex
property", where its a grouping of descriptors that is not ever meant to be
a standalone object. Therefore, it doesn't have a source.

On Thu, Feb 8, 2018 at 5:24 AM, Alex Jackl <alex@bardicsystems.com> wrote:

> Oh - I took it as a given that both the technical source and target need
> to be defined in an alignment object.  It is literally a wasted thing
> otherwise.
>
> I appreciate you can repeat the property but can you have the same object
> with a different alignment ?  And have that be discoverable?  And have
> metadata on that?  I get it is more complicated and thus not in keeping
> with schematic.org’s STRONG and understandable need for simplicity, but I
> think the use case is there.
>
> Sent from my iPhone
>
> On Feb 8, 2018, at 8:16 AM, Phil Barker <phil.barker@pjjk.co.uk> wrote:
>
>
>
> On 08/02/18 13:03, Alex Jackl wrote:
>
> Isn’t an alignment object necessary though when different political
> contexts or different organizations may not agree on the same controlled
> vocabulary for relationships?
>
> No, I don't think it is. You can repeat any property you like in
> schema.org, whether it points to an AlignmentObject or a DefinedTerm. The
> latter has the better mechanism for linking to information about the
> framework / DefinedTermSet
>
> I don’t see how you get around that need if you are building a
> sustainable, enterprise style standard for this sort of thing.
>
> I would think you absolutely would want to add Source identification on
> such an object as that is part of the point- WHOSE alignments do you
> trust?
>
>
> There's maybe a case to be made for that (but so far little evidence of
> people using AlignmentObjects), but that's not the source Fritz was
> meaning. He meant source* properties as the opposite of target* properties,
> i.e. pointing back to the learning resource that was aligned to the
> framework.
>
> Phil
>
>
> Sent from my iPhone
>
> On Feb 7, 2018, at 9:59 PM, Fritz Ray <fritley@gmail.com> wrote:
>
> 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
>>
>>
>>
>
> --
>
> 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
>
>