Re: EOCred: cost of a credential

I think you’ll find we agree a bit more here ;-)

I wasn’t suggesting the only way to link Courses and Credentials is via
Offers.  That route is more to link Credentials and Courses to/from the
organisations offering them under potentially varying costs and conditions.

I have no objection to also linking a Course to a Credential by using the
educationalCredentialAwarded
<http://pending.schema.org/educationalCredentialAwarded> property, this has
the benefit of simply pairing one to the other, without having to delve in
to the potentially complex matrix of costs and eligibility.

Coming at this from the Courses direction, this is one of the prime
objectives — defining a structured description (Credential Type) for the
educationalCredentialAwarded
<http://pending.schema.org/educationalCredentialAwarded> property to link
to.

~Richard



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

On 30 January 2018 at 14:13, Phil Barker <phil.barker@pjjk.co.uk> wrote:

>
> On 30/01/18 13:30, Richard Wallis wrote:
>
> On 30 January 2018 at 12:02, Phil Barker <phil.barker@pjjk.co.uk> wrote:
>
>> Richard, I think we mostly agree, we are just looking from different
>> perspectives.
>>
> Good to agree ;-)
>
>
> yes indeed. However, were we differ is that, while could link Courses and
> Credentials via Offers (with a little creative interpretation of
> schema.org definitions), I would rather use educationalCredentialAwarded
> <http://pending.schema.org/educationalCredentialAwarded>. I prefer
> linking Things directly rather than going through abstract and types like
> Offer and its properties.
>
> Phil
>
> I think we are both saying that organizations providing learning
>> opportunities (for simplicity let's say Courses) should give the cost of
>> the Course and link to the Credential may be awarded on completing that
>> Course, and organizations providing Credentials should give the cost of
>> that Credential (and where feasible link to Courses that are suitable).
>>
>> I am wary about AddregateOffer <http://schema.org/AggregateOffer>
>> because it relates to the same item offered by different merchants, not
>> different Courses offered by different Colleges.
>>
> I think, like much of Schema.org, it is a little looser than that, I could
> imagine an AggregateOffer describing:
>
>    - Various routes to obtaining Credential X offered by Organization
>    (college)  Y.
>    - An AggrigateOffer prepared and shared by Organization Y
>    - Various routes to obtaining Credential X offered by various
>    organisations.
>    - An AggregateOffer prepared by an offer aggregation site, showing the
>       market in obtaining credentials.
>
>
> An addOn <http://schema.org/addOn> offer implies that the addOn *can only
>> be obtained *in combination with the base offer. So this is not the case
>> when there are a large number of courses that could lead to the Credential.
>>
> There is not necessarily a 1-2-1 relationship between *addOn*s and the
> Offers they link to.  An organisation could have two specific Credential
> Offers (a. Free with certain in-house courses, b. lots of $$ for standalone
> purchase). Said organisation could offer 6 courses: 3 which have an addOn
> link to the free credential offer; 2 that have an addOn link to the lots of
> $$ credential offer and; 1 that has no addOn link (take our course and use
> its results to get credential from some other organisation).
>
>
>> I suggested a while back in this thread that where there is a closely
>> associated course offered by the same organization [as offers the
>> credential] it may appropriate to use the addOn property to link to this.
>> Where a course is normally required in order to gain a credential, but this
>> course is not offered by the same organization, then [whatever solution we
>> come up with for the use case we have about eligibility requirements]
>> should be used.
>>
> The offeredBy <http://schema.org/offeredBy> property of Offer (both for
> the course and credential) should indicate who is providing the thing being
> offered.  You are correct that where these are the same, *addOn* is
> probably the best way to tie things together.
>
> ~Richard
>
>
>> Phil
>>
>> On 30/01/18 11:27, Richard Wallis wrote:
>>
>> Phil, you make a good point about clarifying the use case(s) in this
>> area.
>>
>> As you identify there are components, and their associated cost(s), and
>> requirements (courses, experience, memberships, previously obtained
>> credentials (eg. from a different jurisdiction), etc.  Dependant on
>> particular users’ circumstances these could easily expand into a
>> significant multi-dimension matrix of possibilities and costs.
>>
>> Going back to Schema.org basics, it is about describing *Things* and
>> their relationships.  In your scenario we have some basic Things
>> (components) — the Credential; the *Organization*(s) which provide the
>> credential; the *Offer*(s) that *Organization*(s) make to provide the
>> Credential detailing/referencing any costs and criteria for a specific
>> Offer; a *Course* that either [if successfully completed] leads to
>> obtaining a Credential or, is a requirement for gaining a Credential; the
>> Organization(s) *Offer*ing the Courses with associated costs etc.
>>
>> Dependant on your view or use, these Things may be related in different
>> ways with either the *Course*, Credential, or *Organization* being seen
>> as the primary searchable component, but if they are related correctly all
>> views should be supportable.
>>
>> As discussed previously, Course <http://schema.org/Course>, Organization
>> <http://schema.org/Organization>, and Offer <http://schema.org/Offer> are
>> already established Types in Schema.org, [with a few tweaks to link a
>> Credential Thing into the model] taking us a long way towards our goal.
>> With the AggregateOffer <http://schema.org/AggregateOffer> subtype, and
>> properties such as addOn <http://schema.org/addOn>, the *Offer*
>> functionality, plus lots of established practice in Schema.org for complex
>> offers to sell Products or loan items, is sufficient to describe our needs,
>> at least initially.
>>
>> A simple case of an Organization offering a course with subsequent
>> credential, or the credential on its own if the applicant had sufficient
>> qualifications from elsewhere.  Could be described with 2-3 *Offer*
>> descriptions:
>>
>>    1. An *Offer* to provide the Credential alone, with specific cost and
>>    description of eligibility (as discussed previously)
>>    2. An *Offer* to provide the *Course*, with specific cost and
>>    description of eligibility, plus an *addOn* *Offer*; which would
>>    either be a link to *Offer* 1., or (if costs/criteria are different
>>    in this case) a link to *Offer* 3.
>>    3. An *Offer* referenced from Offer 2. as the *addOn* *Offer* to
>>    provide the Credential subsequent to completion of the *Course* offered
>>    in *Offer* 2.
>>
>> With the above example it would be perfectly possible to describe a
>> course/credential combination at a single cost.  i.e. Main *Offer *describing
>> the combination cost, linking to specific* addOn Offer *with a zero cost
>> *.*
>>
>> I don’t believe anyone should be responsible for aggregating these costs,
>> but some people/organisations may want to do this at an organisational,
>> regional, or global level, and we should provide the mechanisms to
>> facilitate that as well as describing the individual components fully.  The
>> current *Offer* structure in Schema.org should be sufficient to do this.
>>
>> ~Richard.
>>
>> Richard Wallis
>> Founder, Data Liberate
>> http://dataliberate.com
>> Linkedin: http://www.linkedin.com/in/richardwallis
>> Twitter: @rjw
>>
>> On 30 January 2018 at 10:28, Phil Barker <phil.barker@pjjk.co.uk> wrote:
>>
>>> Stuart, you haven't really addressed what I see as the main problem.
>>> Yes, a college offering a learning opportunity leading to a credential can
>>> quote various prices for that. However, what happens when several colleges
>>> offer courses leading to the same credential? Here's an example, the SQA
>>> HNC/HND in Administrative and Information Technology
>>> <https://www.sqa.org.uk/sqa/67670.html> has at the bottom of the page a
>>> 'Where can you take this course' option (aside:  confusion between course
>>> and qualification is endemic) If you enter Edinburgh or Glasgow in to the
>>> search box you will see a range of providers of courses that lead to that
>>> credential, none of which are SQA. SQA are a relatively simple case, this
>>> is from the Pearson page about a similar English credential
>>> <https://qualifications.pearson.com/en/qualifications/btec-higher-nationals.html>
>>> "BTEC Higher Nationals are delivered at both universities and colleges in
>>> 58 countries around the world"
>>>
>>> Why should SQA or Edexcel be responsible for aggregating the cost of
>>> these courses?
>>>
>>>
>>> I would like to step back a little further than you suggest and think
>>> about the use case before thinking about defining the cost and how to
>>> express it in schema.org. Someone aiming for a credential which
>>> involves study  will know that they have to make a series complex financial
>>> judgements involving tuition fees, living costs, lost income while
>>> studying. I don't think the aim here is that a third party service should
>>> be able collate all of the relevant information from disconnected providers
>>> using schema.org to make some sort of cost comparison site; what we
>>> should be aiming for in meeting this use case is that sources provide clear
>>> information about the relevant component costs that they control so that
>>> the person searching for options can collate them.
>>>
>>> Furthermore, there is a simpler use case of someone who has already
>>> fulfilled the necessary educational requirements and wants to know what it
>>> will cost to get these credentialed. (For example if they are moving
>>> between jurisdictions, or just need an some easy way of verifying that they
>>> are qualified).
>>> For both of these angles on the use case, I think we should clarify the
>>> difference between the cost of the course and the direct cost of the
>>> credential. I don't think either requires that a credentialing
>>> organization  should be involved in aggregating costs of courses from other
>>> people.
>>>
>>> Phil
>>>
>>> SQA HNC: https://www.sqa.org.uk/sqa/67670.htm
>>> EdExcel BTEC: https://qualifications.pearson
>>> .com/en/qualifications/btec-higher-nationals.html
>>>
>>>
>>> On 29/01/18 19:11, Stuart Sutton wrote:
>>>
>>> I'd like for a moment to stick close to finding a definition for cost
>>> and look to it's expression in the context of schema.org as a next
>>> step. I agree, Phil, cost can be "tricky"--in fact, one of the trickiest
>>> and most discussed in the context of the CTDL. Just the range of cost types
>>> is considerable -- see, for example, the CTDL SKOS vocabulary of cost types
>>> at http://purl.org/ctdl/terms/CostType. Layer on that any instance of
>>> these costs types can be further conditioned on other factors such as the
>>> type of person seeking the credential (e.g., see CTDL SKOS audience
>>> vocabulary at http://purl.org/ctdl/terms/Audience). And, cost can be
>>> even further qualified by geographic region in which the credential is
>>> offered etc, etc, etc.
>>>
>>> So, down in the weeds, yes, complex; BUT, even faced with such
>>> complexity, I don't know of a single purveyor of a  credential that can't
>>> (or doesn't) respond in public to the question: "What's the typical cost of
>>> this credential?" In fact, that information is frequently available on the
>>> website -- look at this page for a culinary arts certificate from a U.S.
>>> 2-year community college (https://portal.santarosa.edu/
>>> srweb/SR_GainfulEmployment.aspx?MCID=1462). Note that the amounts
>>> stated are typical and qualified by the caveat of varying
>>> times-to-credential.
>>>
>>> On Mon, Jan 29, 2018 at 7:20 AM, Richard Wallis <
>>> richard.wallis@dataliberate.com> wrote:
>>>
>>>> On 29 January 2018 at 15:02, Phil Barker <phil.barker@pjjk.co.uk>
>>>> wrote:
>>>>
>>>>
>>>>> If you want the cost to include the learning opportunity then I think
>>>>> we will need a new property along the lines of "typical aggregated cost".
>>>>>
>>>>
>>>> I think this would not be an advisable route to take.
>>>>
>>>> The costs of such learning opportunities should be defined in an
>>>> *Offer* by the provider of that opportunity, possibly linked to the
>>>> EOC via Offer->addOn.
>>>>
>>>> As to a “typical aggregated cost” - who would do the aggregating and
>>>> calculation of what is typical? - a minefield for confusion and out of date
>>>> data.
>>>>
>>>
>>> I agree with Richard that "typical aggregate cost" is confusing in terms
>>> of what's in an aggregation and what is not. But, constrained by definition
>>> to: (a) tuition and fees where the means of verifying credential
>>> competencies is some form of learning opportunity, or (b) costs of
>>> assessment where the verification is by stand-alone-assessment is tractable
>>> -- and very meaningful in answering: "What's the typical cost of this
>>> credential?"
>>>
>>> Richard, is there any evidence that such a solution --in markup-- would
>>> be any more subject to out of date data than markup of costs somewhere for
>>> a Sony Model X.
>>>
>>> --Stuart
>>>
>>>
>>>>
>>>> ~Richard.
>>>>
>>>>
>>>>>
>>>>> On 27/01/18 14:58, Stuart Sutton wrote:
>>>>>
>>>>> Phil, I'm a bit uneasy about the scoping and (slightly about) the
>>>>> definition.  In scoping you state:
>>>>>
>>>>> *Cost*
>>>>> *Having found a credential it should be possible to identify the cost
>>>>> of acquiring the credential.*
>>>>>
>>>>>
>>>>>            Constraint
>>>>>
>>>>> *This is the cost of the credential itself, not the cost of courses,
>>>>> training or other things required in order to earn the credential (these
>>>>> costs can be shown when describing those other things).*
>>>>>
>>>>>
>>>>> People looking for the cost of a credential are seldom interested in
>>>>> costs pertaining to the mechanics of the award and very interested in
>>>>> direct costs of attaining the credential. I think those "other things" you
>>>>> mention boil down to cost of verification of competencies attained by: (1)
>>>>> some form of independent assessment (e.g., my California State Bar exam to
>>>>> earn a license to practice law), or a learning opportunity (course (of
>>>>> study), apprenticeship or other form of verified experience), e.g., my law
>>>>> degrees. So, wouldn't people looking for a credential they can afford want
>>>>> some estimated direct costs stemming from any necessary assessment or
>>>>> learning opportunity. In many/most cases, the only direct cost of a
>>>>> credential are the costs of independent assessment and/or learning
>>>>> opportunity.
>>>>>
>>>>> I appreciate wanting to slice and dice this so that the costs attached
>>>>> to a required schema.org/Course (of study) are expressed there (and
>>>>> should be), and the costs of any independent assessment (no current
>>>>> schema.org entity) are expressed there (and should be), but someone
>>>>> searching for a credential they can afford would want to see the direct
>>>>> costs rolled up.
>>>>>
>>>>> Phil, what's meant by "objects" in "Requires: ability to show
>>>>> relevant cost for educational / occupational credential objects"?
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 26, 2018 at 2:40 AM, Phil Barker <phil.barker@pjjk.co.uk>
>>>>> wrote:
>>>>>
>>>>>> I want to try and keep some momentum by doing some of the quick and
>>>>>> easy use cases while we discuss the more difficult ones. I think this is
>>>>>> one:
>>>>>>
>>>>>> Cost
>>>>>> Having found a credential it should be possible to identify the cost
>>>>>> of acquiring the credential.
>>>>>>
>>>>>> Requires: ability to show relevant cost for educational /
>>>>>> occupational credential objects
>>>>>> Note: this implies that a credential is offered
>>>>>>
>>>>>> This is the cost of the credential itself, not the cost of courses,
>>>>>> training or other things required in order to earn the credential (these
>>>>>> costs can be shown when describing those other things).
>>>>>>
>>>>>> schema.org has means for specifying the cost of things with the
>>>>>> offers <http://schema.org/offers> property which we could use. If
>>>>>> EducationalOccupationalCredential is a CreativeWork, then we already
>>>>>> have the offers property (if it is not, we may need change the domain of
>>>>>> the existing offers property)
>>>>>>
>>>>>> A simple example
>>>>>>
>>>>>> {
>>>>>>   "@context": "http://schema.org/" <http://schema.org/>,
>>>>>>   "@type": "EducationalOccupationalCredential",
>>>>>>   "url" : "https://www.alt.ac.uk/certified-membership"
>>>>>> <https://www.alt.ac.uk/certified-membership>,
>>>>>>   "name": "CMALT",
>>>>>>   "description": "Certified Membership of the Association for
>>>>>> Learning Technology",
>>>>>>   "offers": {
>>>>>>     "@type": "Offer",
>>>>>>     "name": "Registration fee (UK)",
>>>>>>     "price": "150",
>>>>>>     "priceCurrency": "GBP"
>>>>>>   }
>>>>>> }
>>>>>>
>>>>>> Offers <http://schema.org/Offer> can get quite complex, allowing
>>>>>> different currencies, different offers for different regions, add on offers
>>>>>> etc.  I think it would cover our needs adequately; the only potential
>>>>>> problem I can see is that eligibleCustomerType as defined is too
>>>>>> restrictive to provide information like "special price for military
>>>>>> veterans". My approach to this would be to 1) raise this as an issue with
>>>>>> schema.org. 2) provide text values anyway (schema.org allows this)
>>>>>>
>>>>>> Any objections? Have I missed anything?
>>>>>>
>>>>>> Phil
>>>>>> --
>>>>>>
>>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>> --
>>
>> 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
>>
>
>
>
> --
>
> 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
>