Personal competency profile information service using HR XML competency

• Personal competency profile information service

In this expression, it is assumed that the profiles to be communicated are well-defined structures specified in accordance with the HR-XML Competencies spec. (See the background discussion separate document for background on the choice of specs for expressions of this genre.)

The HR-XML Specification: “Competencies (Measurable Characteristics) Recommendation, 2006 Feb 28”, section 1.1.3, gives the following rationale for the schema:

“The HR-XML Consortium’s competencies schema is designed as a reusable schema fragment that might be applicable to a wide range of business processes. Generally speaking, the schema could potentially be useful in any process involving the comparison, matching, weighting, or rating of a competency demanded against an actual available competency.”

Using the HR-XML Competencies spec, the basic request for this expression could be thought of as a request to “provide just the information held about this person asked for in this request”, and the response will comprise just information that matches the specified list of competencies, and that also have permission to be sent to the requesting party.

Because of the nature of the HR-XML representation, it is possible to have a person specification (spec) represented in HR-XML as well as a personal profile. This results in two realistic possibilities for the way in which this service can work: firstly that the profile is constructed and given against a list of competencies, and secondly that the profile is in response to a specification profile. The difference is that in the first case the competency map does not have any scale information attached to the list of competencies; in the second case it does. This is like requesting, in the first case, an individual’s competence in mathematics, in contrast to the second case, where the request is whether the individual has a grade A at GCSE Mathematics.

The first of these options, using a competency map, has similarities with another expression of this genre, “Personal competency profile information service using IMS ePortfolio”. The focus in this expression is therefore on the alternative of using profiles instead of maps for specifying the information requested.

For the contents and syntax of the parts of the requests, see below under Data Definitions.

get-personal-profile-information

input: person ID, model competency profile (optional)

output: person ID, model competency profile (optional), competency profile

A provider of the profile information service is here requested to provide a competency profile for an individual against the supplied person specification.

If the person ID is not recognised by the profile information system, the person ID is returned with two blank or empty competency profiles.

If the person ID is recognised, and none of the items on the competency map are recognised, the person ID is returned with two empty competency profiles.

The model profile returned comprises all the competency items which have been recognised. Items which are not recognised are removed from the model profile before return.

For all recognised model profile items, all permitted information is returned as part of the competency profile. For any such map item, it may be that there is no relevant information, or that the relevant information is not permitted to be sent to that body.

The model profiles are not required if the delivered profile is not an actual personal competency profile, but instead a person specification. In this case, the competency profile returned may have the nature of a model competency profile.

send-personal-profile-information

output: person ID, model competency profile (optional), competency profile

The service sends an unsolicited competency profile. This may, for example, be send as an attachment by e mail, or through a web site. In the case of a web site, no immediate acknowledgement of contents is to be expected, but only the notification that a file has been received. The model competency profile is optional in the case where the competency profile is fully defined by its content, as in the case of a person specification.

receive-personal-profile-information

input: person ID, model competency profile (optional), competency profile

output: acknowledgement

This is the other side of send-personal-profile-information, when unsolicited. The default behaviour here would be to merge or update the received information with any existing information. That is, where the information has the same attribute ID, the new information replaces the old, but all information for attributes that not identified identically is retained.

delete-personal-profile-information

input: person ID, model competency profile

output: person ID, model competency profile, personal competency profile (as deleted)

This service may be required in some implementations, but not in others. The service deletes, or requests deletion of, all information relating only to the competencies in the model profile supplied, and returns a profile equivalent to all the information successfully deleted.

DATA DEFINITIONS:

These form a vital supplement to the behaviours and requests.

person ID

Any string that is recognised by the profile information service as representing a person for whom profile information is stored, or a person spec representing a model applicant. This is not defined here, as it should relate to common practice in other domains and services.

model competency profile

This should be a single file containing at least one HR-XML competency elements.

Each competency element should include:

• “required” set to true if the competency is a requirement in the context, otherwise set to false if information about the competency is invited but not required
• a CompetencyID element referring to the URI/IRI of the published competency definition
• optionally, a TaxonomyID element referring to a competency map containing and describing the individual competency definitions
• optionally, a CompetencyWeight element expressing the relative weights of the various solicited competencies
• optionally, a CompetencyEvidence element with “required” set to true if evidence is required, an optional typeDescription describing the type of evidence solicited, an optional NumericValue or StringValue to specify a required level on an agreed rating scale, and optional SupportingInformation in general explanation.

competency profile

This should be a single file containing a set of HR-XML competency elements.

Each competency element should include:

• a CompetencyID element referring to the URI/IRI of the published competency definition – this should be identical to the corresponding CompetencyID in the model competency profile, if present
• optionally, a TaxonomyID element referring to a competency map – if present, this should be identical to the same element in the model profile
• optionally, any number of CompetencyEvidence elements, with optional typeDescription, optional NumericValue or StringValue to specify an attained level on an agreed rating scale, and optional SupportingInformation

The person or body requesting the profile information will have to ascertain the relevant person ID in a different way, not through this service. It is imagined that the person ID would be provided in some way from the profiled person.

The main scenario of use is where an admissions service, or HR department, is examining the application of an individual for admission or employment. They will assemble the person ID provided by the individual together with the model competency profile relevant to the business purpose, and this provides what is necessary to fill the get-personal-profile-information input. This request is sent to the profile information service managing the information of that individual. The returned model competency profile is matched against the input given, in case there may be some competencies left off, and the provided profile is parsed and stored in the relevant database.

Other uses and interactions surrounding get-personal-profile-information are similar in nature, though they may differ in purpose.

The pair of services: send-personal-profile-information and receive-personal-profile-information are for asynchronous use. A course, or position, may be publicly advertised, and the personal profile which specifies the kind of person sought is also made available. The specification profile could be requested with a get request probably without a model profile, as the model is likely to be defined by the body specifying the opening. The person interested in the course or job would then send profile information tailored to that person specification.

Deletion would in practice be done in conjunction with the more common “get” service. First the information relevant to the items on the map would be requested, to see what there is present. Then the deletion request may be issued. The profile returned from the delete request can be compared with the get profile, to ascertain which information was not deleted.

Because of the undetermined nature of the storage, it will not be possible to know simply on the basis of the returned profile what it is that is able to be deleted. But this service would be used on the presumption that the owner of the information would like it deleted wherever it is. It may be as likely, or more so, that deletion would be done on a server-by-server basis, where the nature of the permissions involved is clearer.

Not yet appropriate at this stage

 

 

See the background document for considerations regarding choice of this or another expression.

The general situation envisaged in the context of this service is for the information to be distributed around different servers. In this case, there is the potential for dependency upon services concerned with distributed file storage, or repositories.

The definition and specification of PersonID should be integrated with other services.

It is possible to envisage automatic matching of personal profiles against a person specification, if certain conditions are met. The CompetencyID values should match exactly; the CompetencyEvidence typeID values should be the same, the values should be numeric, and the numeric value in the personal profile should fit in with any minValue and maxValue specified in the model profile. At very least, this needs an agreed typeID vocabulary, and other issues may well emerge.

In practice, it may emerge that a richer “assessment” model is needed to support automatic matching of profiles against requirements, not constrained by the given HR-XML syntax.

 

HR-XML Competencies

 

 

 

 

 

 

 

Pending

1

 

2006-08-22

Simon Grant

Last updated 30 January 2008