- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Tue, 30 Jan 2018 14:13:52 +0000
- To: public-eocred-schema@w3.org
- Message-ID: <dbd1062c-886a-97aa-3311-84b244585437@pjjk.co.uk>
On 30/01/18 13:30, Richard Wallis wrote:
> On 30 January 2018 at 12:02, Phil Barker <phil.barker@pjjk.co.uk
> <mailto: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.
> o An AggrigateOffer prepared and shared by Organization Y
> * Various routes to obtaining Credential X offered by various
> organisations.
> o 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
>> <http://www.linkedin.com/in/richardwallis>
>> Twitter: @rjw
>>
>> On 30 January 2018 at 10:28, Phil Barker <phil.barker@pjjk.co.uk
>> <mailto: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
>> <http://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 <http://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
>> <https://www.sqa.org.uk/sqa/67670.htm>
>> EdExcel BTEC:
>> https://qualifications.pearson.com/en/qualifications/btec-higher-nationals.html
>> <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 <http://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
>>> <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
>>> <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
>>> <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
>>> <mailto:richard.wallis@dataliberate.com>> wrote:
>>>
>>> On 29 January 2018 at 15:02, Phil Barker
>>> <phil.barker@pjjk.co.uk <mailto: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
>>>> <http://schema.org/Course> (of study) are expressed
>>>> there (and should be), and the costs of any
>>>> independent assessment (no current schema.org
>>>> <http://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
>>>> <mailto: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 <http://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 <http://schema.org>.
>>>> 2) provide text values anyway (schema.org
>>>> <http://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
>>>> <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
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>
>>
>
> --
>
> 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
Received on Tuesday, 30 January 2018 14:14:22 UTC