Re: EOCred: Identify the level of a credential

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 property to point to an 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[*] 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/confpaper/analysing-improving-embedded-markup-learning-resources-web/
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Phil Barker. http://people.pjjk.net/phil
>>>>> PJJK Limited: 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
> PJJK Limited: 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