Re: Please add property="skill" to the typeOf="Person"

“I wouldn’t start from here” (
http://www.barrypopik.com/index.php/new_york_city/entry/i_wouldnt_start_from_here_joke)
comes to mind. If we were starting from a blank slate, then maybe we would
consider 'competencies'. However given the existence of 'skills' (+ 'Role'
and 'PropertyValue') perhaps we have enough raw materials to make quick
progress.  It would be good to talk about competencies in the definition,
at least.

Currently "skills" is applied only to JobPosting, and is defined as "Skills
required to fulfill this role". We could extend the property to be
applicable to Person and perhaps other kinds of thing, but it would need a
new definition. It would be good if the nature of the relationship between
the thing and the skill(s) were as consistent as possible across types and
scenarios.

In current usage the skills are those needed in the (job) role. If we allow
the same property on Person, the most natural reading is that it lists some
of the skills that Person has.

Could we say:  """The "skills" property lists skills that a Person has, or
that a JobPosting expects a Person meeting an employment role to have. """

It is always appealing to generalize. We might be tempted to add something
about CreativeWorks and Events and maybe other types, in terms of
pre-requisites for understanding or attending. Note that we already have
the property https://schema.org/dependencies squirreled away against
TechArticle ("Prerequisites needed to fulfill steps in article.").
 Furthermore there is also http://schema.org/audience ("An intended
audience, i.e. a group for whom something was created"), as well as other
pieces of vocabulary such as http://schema.org/typicalAgeRange. As Stuart
is very well aware there are also substantial metadata communities (lately
around LRMI/Dublin Core) interested in describing skills, competencies, and
learning resources in ways that tie into the wider landscape for job
descriptions, training opportunities etc. The potential for a grand
integration here is very compelling, but I'd like to identify a simple
first step. Can we make a minimal short-term fix to "skills" that allows it
to be attached to Person, that allows simple strings, property/value pairs,
and URL  references to be used, ... and then step back and look at the
wider landscape of competency frameworks, controlled value lists and so on?

cheers,

Dan

On 3 May 2017 at 16:01, Thad Guidry <thadguidry@gmail.com> wrote:
>
> Vicki,
> ah yes, forgot that time-mediation was part of Role itself !  Problem
solved there.
> So it would look like this I guess once skills is added as allowed to
Person
>
> <script type="application/ld+json">
>     {
>       "@context": "http://schema.org",
>       "@type": "Person",
>        "name": "Delia Derbyshire",
>        "sameAs": "http://en.wikipedia.org/wiki/Delia_Derbyshire",
>        "skills": {
>          "@type": "Role",
>          "skills": "typing, knitting",
>         "startDate": "1959"
>       }
>     }
>     </script>
>
> -Thad
> +ThadGuidry
>
>
>
> On Wed, May 3, 2017 at 9:33 PM Vicki Tardif Holland <vtardif@google.com>
wrote:
>>
>> Respectfully, we already have http://schema.org/skills. Can we use that
to avoid adding another term to the flat namespace?
>>
>> http://schema.org/Role was mentioned. Why isn't that sufficient for
date-mediated skills?
>>
>> - Vicki
>>
>>
>> On Wed, May 3, 2017 at 8:22 AM, Martin Hepp <mfhepp@gmail.com> wrote:
>>>
>>> I would suggest to consider a subtype of http://schema.org/PropertyValue
for representing skills. This will give a lot of flexibility while
preserving data granularity from the source.
>>>
>>> -----------------------------------
>>> martin hepp  http://www.heppnetz.de
>>> mhepp@computer.org          @mfhepp
>>>
>>>
>>>
>>>
>>> > On 03 May 2017, at 12:29, Stuart Sutton <sasutton@dublincore.net>
wrote:
>>> >
>>> > I would suggest using competence  ("The ability to do something
successfully or efficiently"...Synoyms "capability, ability, competency,
proficiency, accomplishment, expertise, skill, prowess, mastery, talent".
>>> >
>>> > On Tue, May 2, 2017 at 9:14 PM, Michael Andrews <
nextcontent01@gmail.com> wrote:
>>> > I agree there's a need to be able to represent skills in schema.org.
To make the implementation serve the needs of many, I suggest considering
the following:
>>> >
>>> > -- Don't tie skills with job titles.  People can have active skills
that aren't used in their current position (e.g., they are a native speaker
of a language when in a job that doesn't require that language.)  People
may have skills developed or available for volunteer experiences that
aren't formal jobs.
>>> > -- People may also have multiple, concurrent, overlapping jobs,
rather than serial jobs with clearly defined start and end dates. Job
titles can be a poor indication of what someone is doing when people are
doing multiple roles at once.  For people with portfolio careers, it makes
more sense to speak of "projects" rather than job titles, with the project
involving one or more roles.
>>> > -- Consider a broader category of "expertise" to capture less
task-oriented knowledge.  An academic might have expertise on bond markets
or privacy law, even though they are not a bond trader or a practicing
lawyer.
>>> >
>>> > Michael
>>> >
>>> >
>>> >
>>> > On Wed, May 3, 2017 at 5:58 AM, Thad Guidry <thadguidry@gmail.com>
wrote:
>>> > Please consider...
>>> >
>>> > Lost skills.  Historical skills.  I used to be an aerospace mechanic,
I no longer have those skills (well a few but many I have forgotten). I am
now a Data Architect.
>>> > We want to allow for time-mediation of skills as well. And a way for
someone to say what their "CURRENT" skills are.
>>> >
>>> > "CURRENT" against any particular skill needs to be captured.  This
can be done with a property called "currentSkills" on Person.
>>> >
>>> > For everything else...What we need is to finish the effort of the
existing CV/Resume proposal here
https://github.com/schemaorg/schemaorg/issues/603
>>> >
>>> > jobTitle
>>> > worksFor
>>> > workLocation
>>> >
>>> > are for "CURRENT" status of a Person.  And I would argue that those
need to be prefixed with "current" such as "currentJobTitle", etc.
>>> >
>>> > But we also want time-mediation for all of those, not just
current...I.E., a history of a persons employment.  That is captured in the
proposal above.
>>> > And with that proposal, there would be a "cv/resume" property that
expects a type of CV/RESUME that can allow for much more flexibility and
time-mediation.
>>> >
>>> > In fact, time-mediation is needed in a lot of areas of Schema.org.
We might even consider some higher level abstraction of time-mediation
against any particular property when it is needed..  Just as Wikidata and
others do.
>>> > But this will need Guha's deep thought processes :)
>>> >
>>> > -Thad
>>> > +ThadGuidry
>>> >
>>> >
>>> > On Wed, May 3, 2017 at 7:54 AM Nicolas Torzec <torzecn@yahoo-inc.com>
wrote:
>>> > Hi Maxim,
>>> > I like the idea of adding a 'skill' property to schema.org/Person for
capturing Resumes.
>>> >
>>> > In addition, you probably want to use a reified version of
'affiliation' and 'alumniOf' so you can use them as roles with startDate
and endDate.
>>> >
>>> > See http://blog.schema.org/2014/06/introducing-role.html
>>> >
>>> > Cheers.
>>> > N.
>>> >
>>> >
>>> > On Monday, May 1, 2017, 5:24:14 AM PDT, Maxim Angel <
maxim_angel@live.co.uk> wrote:
>>> > Please add property "skill" to "Person" type, so many people want to
use
>>> > schema.org/Person for creating CV
>>> >
>>> >
>>>
>>>
>>