Re: EOCred: cost of a credential

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 ;-)


> 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
>