Re: EOCred: Identify the level of a credential

“I think text is good, I’d really like to add URL"

That is no problem - it is default in Schema.org to be able to use a URL
(if you have one) for the value of any property:

*some types such as Role and URL can be used with all properties, and we
encourage this kind of experimentation amongst data consumers.
<http://schema.org/docs/datamodel.html#conformance>*




Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw

On 17 February 2018 at 10:20, Fritz Ray <fritley@gmail.com> wrote:

> Phil,
>
> Your understanding continues to make sense to me. I didn't realize the
> credentials for each level of award were nationalized... I don't believe
> that changes anything.
>
> Nate,
>
> I could imagine educationLevels being described as:
>
> "Masters"
> "SPQF Level 5"
> Taxon/DefinedTerm/reserved URL such as http://ed.gov/degreeLevels/
> associates
> by URLs to documents.
> <https://www2.ed.gov/about/offices/list/ous/international/usnei/us/associate.doc>
>
> That's primarily why I chose a set of things that broad. I'd agree it
> doesn't serve the use cases, but there are a lot of cases where these
> levels are defined in documents, so text strings is about all we're going
> to get.
>
> I assume that at some point the web of data people will win and all these word
> documents
> <https://www2.ed.gov/about/offices/list/ous/international/usnei/us/edlite-structure-us.html>
> and pdfs
> <http://scqf.org.uk/wp-content/uploads/2014/03/SCQF-Level-Descriptors-WEB-Aug-2015.pdf>that
> describe levels will have corresponding URLs for each level.
>
> Richard et al,
>
> I think text is good, I'd really like to add URL in order to represent
> taxons and links to descriptions of levels out on the web (so we're at
> least somewhat as capable as AlignmentObject.)
>
> Other than that, I'm happy with where the conversation has ended up.
>
> On Fri, Feb 16, 2018 at 10:33 AM, Vicki Tardif <vtardif@google.com> wrote:
>
>> Based on similar experiences in other Schema.org extension areas, when it
>>> has become complex/difficult to gain consensus on a particular point,
>>> especially with an initial proposal:
>>> I suggest that we agree on a property name for this (these) concepts and
>>> create it with a range of Text and a suitable, not too specific,
>>> description.
>>> After some use in the real world, we can then review that usage and come
>>> up with enhanced propert(ies) definition, range, etc. as part of a further
>>> following proposal.
>>
>> At this current stage translating the forgoing discussions in this email
>>> trail into a concise description, that will be understandable to the
>>> Schema,org community that will receive, and hopefully accept, our proposals
>>> seems a challenge too far for this initial release.
>>
>>
>> I agree with Richard. It may be simplest to use text and see where the
>> data leads us.
>>
>> - Vicki
>>
>> On Fri, Feb 16, 2018 at 12:42 PM, Richard Wallis <
>> richard.wallis@dataliberate.com> wrote:
>>
>>> Based on similar experiences in other Schema.org extension areas, when
>>> it has become complex/difficult to gain consensus on a particular point,
>>> especially with an initial proposal:
>>>
>>> I suggest that we agree on a property name for this (these) concepts and
>>> create it with a range of Text and a suitable, not too specific,
>>> description.
>>>
>>> After some use in the real world, we can then review that usage and come
>>> up with enhanced propert(ies) definition, range, etc. as part of a further
>>> following proposal.
>>>
>>> At this current stage translating the forgoing discussions in this email
>>> trail into a concise description, that will be understandable to the
>>> Schema,org community that will receive, and hopefully accept, our proposals
>>> seems a challenge too far for this initial release.
>>>
>>> ~Richard
>>>
>>> Richard Wallis
>>> Founder, Data Liberate
>>> http://dataliberate.com
>>> Linkedin: http://www.linkedin.com/in/richardwallis
>>> Twitter: @rjw
>>>
>>> On 16 February 2018 at 17:39, Nate Otto <nate@ottonomy.net> wrote:
>>>
>>>> Thanks for digging in to get more precise on level here.
>>>>
>>>> I like how the SCQF reasons about levels of accomplishment. A
>>>> Credential can recognize a level of accomplishment, a level of performance,
>>>> or both. A Course could be "at" a level of accomplishment in terms of
>>>> difficulty or prerequisite knowledge & skills. These are good use cases to
>>>> target, and if I think of "educationalLevel", this would be the sense of
>>>> level that would fit best, versus "level of performance", even though it
>>>> would be possible to split hairs further between the two categories I
>>>> started with, which we could abbreviate to "accomplishment level
>>>> recognized" and "accomplishment level required".
>>>>
>>>> This vocabulary's ability to describe level of accomplishment should be
>>>> distinct from trying to talk about level of performance and not use the
>>>> same property, in my opinion.
>>>>
>>>> Fritz,
>>>> I'm a little wary of "A string, term or URL". That's amazingly broad to
>>>> the point where it would likely make it very difficult to serve the
>>>> comparison use cases.
>>>>
>>>> What feels important to me about understanding the level of
>>>> accomplishment of a credential is its position relative to other
>>>> credentials, learning opportunities, etc. I am not confident I get that
>>>> across a range of credentials unless they all use specific URLs pointing to
>>>> level definitions like the ones from the SCQF.
>>>>
>>>> On one hand, one string property is nice and simple, on the other hand,
>>>> it doesn't serve comparison use cases well unless all the credentials you'd
>>>> like to compare use a very specific scheme established outside the scope of
>>>> this vocabulary known to the consumer.
>>>>
>>>> Maybe I changed my mind on using alignment, particularly because
>>>> AlignmentObject already has the "alignmentType" property, which includes
>>>> "educationalLevel" as an option. We could suggest something like this,
>>>> adding a numerical levelNumber property and using a URL either for
>>>> educationalFramework or targetUrl (a little wary of targetUrl because I
>>>> would think that should represent a URL of the exact level that alignment
>>>> is desired for, but maybe somebody can ease my mind on this point)
>>>>
>>>> {
>>>> "@context": "http://schema.org",
>>>> "@type": "Credential",
>>>> "alignment": [{
>>>> "educationalFramework": "http://pinballsorcerers.org/levels/2",
>>>> "alignmentType": "educationalLevel",
>>>> "levelNumber": 2
>>>> },
>>>> {
>>>> "educationalFramework": "https://ec.europa.eu/ploteus/
>>>> content/descriptors-page",
>>>> "alignmentType": "educationalLevel",
>>>> "levelNumber": 7
>>>> }
>>>> ]
>>>> }
>>>>
>>>> It does seems like we're not going to be able to model this nearly as
>>>> well to serve comparison use cases with a bare text string. Only human
>>>> eyeballs could make sense of the difference between
>>>>
>>>> "educationalLevel": "Pinball Wizard Level 1: Nub" and
>>>> "educationalLevel": "Pinball Wizard Level 6: Ultimate Extra Baller"
>>>>
>>>> Nate
>>>>
>>>>
>>>
>>
>