Fwd: Re: [TalentSignal] Better more flexible coding of Occupational Category

Merrilea raises an important point below.

> To correctly specify O'NET, you'd need to also specify the year of the 
> O'NET revision you're talking about.  It's not naturally part of the 
> name, the way it is with ISCO.  I don't really see a way to do this in 
> the proposed solution (?). But maybe it's obvious and I missed it.

There are two potential solutions.

1) add guidance saying that the year should be added to the name. An 
example might look like:

     "occupationalCategory": {
        "@type": "CategoryCode",
        "inCodeSet": "O*NET (2018)",
        "codeValue": "215",
        "name": "Electrotechnology engineers"
   }

This would do for humans but text names are not great for machines 
(O'NET or O*NET..., and did you know that the US SIC is different to the 
UK SIC?), so maybe better:

2) use CategoryCodeSet <https://schema.org/CategoryCodeSet> as a 
property of inCodeSet, which has some useful properties. An example 
might look like

>      "occupationalCategory": {
>         "@type": "CategoryCode",
>         "inCodeSet": {
>            "@type": "CategoryCodeSet",
>            "name": "O*Net",
>            "datePublished": "2018",
>            "dateModified": "2018",
>            "url": "https://www.bls.gov/soc/2018/"
>         },
>         "codeValue": "215",
>         "name": "Electrotechnology engineers"
>    }
(only one of datePublished and dateModified would be necessary, I'm not 
sure which. O*Net seems more like published, but I know coding schemes 
that seem to be continually modified rather than re-published as a 
whole, so that could be a more general pattern)

Would that work?

Phil

-------- Forwarded Message --------
Subject:  Re: [TalentSignal] Better more flexible coding of Occupational 
Category
Date:  Wed, 24 Apr 2019 08:48:23 -0400
From:  Merrilea Mayo <merrileamayo@gmail.com>
To:  Phil Barker <phil.barker@pjjk.co.uk>



Dear Phil,

I'm replying to you instead of the group in case I just missed 
something.  To correctly specify O'NET, you'd need to also specify the 
year of the O'NET revision you're talking about.  It's not naturally 
part of the name, the way it is with ISCO.  I don't really see a way to 
do this in the proposed solution (?). But maybe it's obvious and I 
missed it.

Merrilea



(tiny keyboard, pls excuse typos)

On Wed, Apr 24, 2019, 8:24 AM Phil Barker <phil.barker@pjjk.co.uk 
<mailto:phil.barker@pjjk.co.uk>> wrote:

    Hello all, there seems to be agreement (or at least a lack of
    dissent) that the two actions that I suggested we start with are
    appropriate. I suggest we tackle them individually, in turn, dealing
    with occupational category first and then job start dates.

    The issue: Better more flexible coding of Occupational Category
    <https://www.w3.org/community/talent-signal/wiki/Better_more_flexible_coding_of_Occupational_Category#Proposal>
    now has its own page on the wiki.

    I have described the issue as: the property occupationalCategory
    definition requires O*Net-SOC taxonomy, which is too prescriptive &
    US-centric. See also issue 2192
    <https://github.com/schemaorg/schemaorg/issues/2192> and PR 2207
    <https://github.com/schemaorg/schemaorg/pull/2207> which adds
    CategoryCode to range of occupationalCategory.

    I have also proposed that to resolve this we:

      *

        Build on PR 2207 to use CategoryCode for occupationalCategory

      *

        Change definition to weaken mandate to use O*Net and to suggest
        alternatives.

      *

        Change definition with respect to handling of textual label,
        formal code and scheme

    I think this is in accord with what Jason suggested
    <https://lists.w3.org/Archives/Public/public-talent-signal/2019Apr/0019.html>.

    There is an additional complicating factor: JobPosting
    <https://schema.org/JobPosting> has both an occupationalCategory
    <https://schema.org/occupationalCategory> and relevantOccupation
    <https://schema.org/relevantOccupation> The latter can be used to
    point to an Occupation <https://schema.org/Occupation> which may
    have an occupationalCategory. So the category could be added to the
    JobPosting either directly or as part of more expressive information
    about the relevantOccupation. The example in PR 2207 (see below)
    takes the latter option. I have asked about this in a comment to
    that PR, but would be interested in any thoughts about it here.

    I suggest the following as a *new definition for
    **occupationalCategory:*

>     Category or categories describing the job. Use a taxonomy such as
>     BLS O*NET-SOC http://www.onetcenter.org/taxonomy.html , ISCO-08
>     https://www.ilo.org/public/english/bureau/stat/isco/isco08/ or
>     similar. Ideally the taxonomy identifier, category textual label
>     and formal code should be provided, with the property repeated for
>     each applicable value.
>
>     Note: for historical reasons any textual label and formal code
>     provided as a literal may be assumed to be from O*NET-SOC

    *Please let me know of suggested changes or alternatives to these
    actions and definition.*

    I have also included an example that is part of Richard Wallis's
    pull request.

>     <script type="application/ld+json">
>     {
>        "@context":"http://schema.org/"  <http://schema.org/>,
>        "@type": "JobPosting",
>        "name": "Systems Research Engineer",
>        "hiringOrganization": {
>          "@type": "Organization",
>          "name": "ACME Software",
>        },
>        "relevantOccupation": {
>          "@type": "Occupation",
>          "name": "Research Engineer - Electronic, Electrical and Telecommunications Systems",
>          "occupationalCategory": {
>             "@type": "CategoryCode",
>             "inCodeSet": "ISCO-08",
>             "codeValue": "215",
>             "name": "Electrotechnology engineers"
>        }
>     }
>     </script>

    Please let me know if you are happy with this.**We could, for
    example, add more information (e.g. the URL) about the CodeSet
    (ISCO-08) being used.

    Best regards, Phil



    -- 

    Phil Barker <http://people.pjjk.net/phil>. http://people.pjjk.net/phil
    CETIS LLP <https://www.cetis.org.uk>: a cooperative consultancy for
    innovation in education technology.
    PJJK Limited <https://www.pjjk.co.uk>: technology to enhance
    learning; information systems for education.

    CETIS is a co-operative limited liability partnership, registered in
    England number OC399090
    PJJK Limited is registered in Scotland as a private limited company,
    number SC569282.