- From: Fritz Ray <fritley@gmail.com>
- Date: Thu, 25 Apr 2019 09:28:31 -0700
- To: public-talent-signal@w3.org
- Message-ID: <CADgY+agCaLaBuL7NyZesg-5Db2eGiKyqrLVNURqALH3d2Qg9cw@mail.gmail.com>
Yeah, ultimately I agree with what was done here, because the world doesn't
entirely turn on linked data... yet.
Updated seems to make more sense. schema.org/datePublished is described as
"Date of first broadcast/publication." Taking a common sense understanding
of that, and not the "Well the changed code set was first published in
2019....." route, dateUpdated seems more appropriate when a specific
version is desired.
On Thu, Apr 25, 2019 at 9:19 AM Phil Barker <phil.barker@pjjk.co.uk> wrote:
>
> On 25/04/2019 16:46, Fritz Ray wrote:
>
> I have internal gripes that the examples aren't great linked data, but
> from a descriptive data standpoint, this looks good.
>
> Fair point, and thanks.
>
>
> The ideal case would be that the occupationalCategory links to the Computer
> System Analysts webpage
> <https://www.onetonline.org/link/summary/15-1121.00> that is either
> Schema.org data or Schema enriched HTML -- and self-describes in a
> consistent fashion. I don't see any problems with that use case either.
>
> I don't know the details of O*Net linked data provision, AFAIK there isn't
> any for the O*Net 2010 edition used in the original example. For the 2019
> update, is this better?
>
> <script type="application/ld+json">
> {
> "@context": "http://schema.org/" <http://schema.org/>,
> "@type": "JobPosting",
> "name": "Systems Research Engineer",
> "hiringOrganization": {
> "@type": "Organization",
> "name": "ACME Software"
> },
> "occupationalCategory": {
> "@type": "CategoryCode",
> "inCodeSet": {
> "@type": "CategoryCodeSet",
> "name": "O*Net-SOC",
> "dateUpdated": "2019",
> "url": " <https://www.bls.gov/soc/2018/>https://www.onetonline.org/" <https://www.bls.gov/soc/2018/>
> },
> "codeValue": "15-1211.00",
> "name": "Computer Systems Analysts",
> "url": "https://www.onetonline.org/link/summary/15-1121.00" <https://www.onetonline.org/link/summary/15-1121.00>
> }
> }
> </script>
>
> Still swithering between updated and published. That url from Fritz say
> updated, so...
>
> Is there are better URI for the term as linked data, that could be used as
> @id?
>
> Of course, if the linked data is fully working, there is no need to put
> the information about the CategoryCodeSet as that could be fetched from the
> URI. However, I think there is no harm in showing how to provide that
> information in an example, and I think it would be necessary to have
> something as a fallback for systems that don't fetch that data.
>
> Phil
>
>
>
> On Thu, Apr 25, 2019 at 3:06 AM Phil Barker <phil.barker@pjjk.co.uk>
> wrote:
>
>> Good point. With a bit more word-smithing:
>>
>> Category describing the job preferably using a term from 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, with the property repeated for each applicable value. Ideally the
>> taxonomy should be identified, and both the textual label and formal code
>> for the category should be provided.
>>
>> Note: for historical reasons any textual label and formal code provided
>> as a literal may be assumed to be from O*NET-SOC.
>>
>> An example showing how the O*NET version can be provided:
>>
>> <script type="application/ld+json">
>> {
>> "@context": "http://schema.org/" <http://schema.org/>,
>> "@type": "JobPosting",
>> "name": "Systems Research Engineer",
>> "hiringOrganization": {
>> "@type": "Organization",
>> "name": "ACME Software"
>> },
>> "occupationalCategory": {
>> "@type": "CategoryCode",
>> "inCodeSet": {
>> "@type": "CategoryCodeSet",
>> "name": "O*Net-SOC",
>> "datePublished": "2010",
>> "url": " <https://www.bls.gov/soc/2018/>https://www.onetcenter.org/taxonomy.html" <https://www.bls.gov/soc/2018/>
>> },
>> "codeValue": "15-1211.00",
>> "name": "Computer Systems Analysts"
>> }
>> }
>> </script>
>>
>> Any more comments?
>>
>> Phil
>> On 24/04/2019 15:03, Stuart Sutton wrote:
>>
>> Phil, if the new definition includes the phrase "...with the property
>> repeated for each applicable value", then you should probably drop "or
>> categories" from the opening phrase since the resulting intention is for
>> the property to identify a single category.
>>
>> In a separate post to this list, I raised a question about a meaningful
>> distinction (asking for one) between 'CategoryCode' and 'DefinedTerm'. It
>> appears to me that the example could be either depending on whether the
>> focus is on the 'name' or the 'codeValue' (I obviously need help).
>>
>> On Wed, Apr 24, 2019 at 5:24 AM Phil Barker <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.
>>>
>> --
>>
>> 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.
>>
> --
>
> 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.
>
Received on Thursday, 25 April 2019 16:29:08 UTC