- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Thu, 8 Feb 2018 13:16:21 +0000
- To: public-eocred-schema@w3.org
- Message-ID: <1d856af5-b2c5-6102-95b4-e2dec4172fba@pjjk.co.uk>
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 > <mailto: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 <mailto: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 <mailto: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 <http://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 <http://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/ >> <https://blogs.pjjk.net/phil/confpaper/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 <mailto: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
Received on Thursday, 8 February 2018 13:16:56 UTC