- From: Phil Barker <phil.barker@pjjk.co.uk>
- Date: Sat, 27 Jan 2018 12:00:34 +0000
- To: public-eocred-schema@w3.org
- Message-ID: <a30543d3-c3d2-47cd-4969-2a296fdadbd7@pjjk.co.uk>
That's great, thanks Fritz. I think I shall raise an issue on the
schema.org git hub repo about eligibleCoustomerType being too
restrictive. Schema.org is constantly evolving, and hopefully (with a
few nudges) it will adapt over time to make use EOCreds and any other
credential-related types that may get added.
We do have a use case requirement about linking jobs / occupations to
credentials, so I think we will come back to that link between
'qualifications' in JobPostings and EOCredentials quite soon.
Regards, Phil
On 27/01/18 06:51, Fritz Ray wrote:
> I'm entirely for putting this off until we have a greater
> understanding, I was just excited to see a benefit that could help
> describe such core objects as Offer, JobPosting, and Demand.
>
> It was primarily in response to your comment about
> eligableCustomerType, in that there may be alternatives to expanding
> eligableCustomerType in Offer, namely bringing 'qualifications' over
> from JobPosting.
>
> On Fri, Jan 26, 2018 at 3:53 AM, Phil Barker <phil.barker@pjjk.co.uk
> <mailto:phil.barker@pjjk.co.uk>> wrote:
>
> Fritz, I think that eligibility requirements (I have learnt that
> qualification is a tricky word) are not the same as credentials
> that show you meet those requirements.
>
> I am not keen on tackling *all* the use cases relating to any type
> of Credential, we have plenty
> <https://www.w3.org/community/eocred-schema/wiki/Use_Cases> of our
> own :) I do think we will circle back to where EOCred sits in the
> schema.org <http://schema.org> type hierarchy when we have a
> better idea of what properties it has, and how many of those
> properties are specifically educational or occupational.
>
> I honestly don't know whether what you suggest is a good idea
> (that's partly why I don't want to get into Credentials in
> general) but I do know that I would like to solve the requirement
> of providing information about the cost of EOCreds without
> spending time thinking about what is required to insure cars.
>
> One of the nice things about schema.org <http://schema.org>'s
> relaxed attitude to expected range is that Offer will work as it is.
>
> Phil
>
>
> On 26/01/18 11:23, Fritz Ray wrote:
>> I feel like we could extend Offer in a way that perhaps takes
>> care of the restrictiveness of eligableCustomerType.
>>
>> If we make a hollow class inbetween CreativeWork and EOC, say
>> CreativeWork > Credential > EOC then we could propose a property
>> in Offer: 'qualifications <http://schema.org/qualifications>'
>> adding a range of 'Credential'
>>
>> The use case I can think of immediately is: One cannot get a bank
>> account without a form of identification (a type of Credential),
>> one cannot buy insurance without a Driver's License. One cannot
>> work in classified areas without a Security Clearance (which is
>> not an EOC)
>>
>> Regional credentials or citizenship could also be required to get
>> different types of offers (a discount if one's a registered
>> veteran, a member of a professional society, or some such) that,
>> as Richard mentioned, could have different pricing.
>>
>> Requires could also be used in other areas.
>>
>> Demand could also have 'requires', for situation where one needs
>> a commercially insured driver, or an individual with a certain
>> degree to satisfy their demand.
>> JobPosting could add Credential to the range of 'qualifications'
>>
>> On Fri, Jan 26, 2018 at 3:04 AM, Richard Wallis
>> <richard.wallis@dataliberate.com
>> <mailto:richard.wallis@dataliberate.com>> wrote:
>>
>> +1
>>
>> I would just add, for those not familiar with Offer
>> <http://schema.org/Offer> a /Thing/ [an
>> EducationalOccupationalCredential in this case] can be the
>> subject of multiple /offers/. Also Offer has an offeredBy
>> <http://schema.org/offeredBy> property linking to the
>> offering organisation or person.
>>
>> These enable use cases of an organisation offering the same
>> /EducationalOccupationalCredent//ial/ at differing costs to
>> different subjects with differing eligibility and; 3rd
>> parties listing disparate organisations offering the same
>> /EducationalOccupationalCredent//ial/.
>>
>> ~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 26 January 2018 at 10:40, 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
>>
>>
>>
>
> --
>
> 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 Saturday, 27 January 2018 12:00:59 UTC