[humanmarkup-comment] RE: Liaison with OASIS HumanMarkup TC?

[Rex Brooks <rexb@starbourne.com>]

Hi again, Chuck,

I am including my previous message because, while I have received a 
post from you through the news@lists.hr-xml.org on 4/11/02, I have 
not received any messages from the competencies mailing list which 
you mentioned. So I thought I would send along this brief reminder 
because I am still very interested in exploring the possibilities of 
synergy between our two groups, and the arena of competencies in 
particular.

I am currently attempting to find someone from an OASIS member 
company associated with our HumanMarkup TC who has some overlapping 
interests in the area of competencies who will also have those 
interests as an incentive to harmonize our different efforts, and act 
as a liaison.

I do have a couple of likely candidates for this role, but I must 
wait for them to obtain permission to participate in this 
crosslinking task.

Joely, Monica, I included you in this message in order to give you 
some background on the specific areas I think you might have some 
interest in developing for human factors and ebXML in international 
applications which could benefit from incorporating Human Markup 
Language-specific contextual depth.

Patrick, Karl and Scott, I wanted to keep you apprised of another 
specific effort to create liaisons between the OASIS HumanMarkup TC 
and other, related, standards organizations.

Warm Regards,
Rex Brooks

Hi Chuck,

Yes, I believe there are synergies we can explore and I would very 
much like to be included in your group's "Competencies" mailing list. 
I agree that we are not on a collision course. I believe we can 
complement each other's specifications in ways that will prove useful 
to the Human Resources Community.

Thanks for your response. I look forward to working with you, and I 
would also like to to suggest that you might find it useful to 
investigate the OASIS Web Services for Interactive Applications 
Technical Committee and perhaps the Web Services for Remote Portals 
TC as well, once it becomes officially established after it's first 
meeting next week. It is almost certain that Human Resources Portals 
offering web services will spring up to serve the Human Resources 
Community.

Regards,
Rex Brooks

At 1:14 PM -0500 3/12/02, Chuck Allen - HR-XML wrote:
>Rex,
>
>It sounds as if HumanMarkup may in some ways be related
>to the work of HR-XML. On the other hand, I don't see our
>initiatives as necessarily on a collision course. Are
>there synergies to explore? Perhaps.
>
>It occurs to me that your work is most closely related to our
>"Competencies" initiative. "Competencies" is a loaded word with
>different meanings in within various disciplines (e.g., human resource
>management, organizational theory, behavioral science, industrial
>psychology, education, etc.) While we have chosen to use the
>familiar, but much debated term "competencies" - what our spec
>really defines is a container to put information about
>"deployment-related characteristics" -- i.e., measurable
>characteristics of a human resource that are relevant in
>determining whether, how, when, etc. that resource is
>deployed within a particular role. The primary use that we
>want to support is the comparison or evaluation of a
>"competency" asserted or claimed against one that is required
>or demanded -- e.g., comparing a skills listed in a resume
>against those outlined in a job description.
>
>The group of people involved in our Competencies spec
>were primarily interested in enabling recruiting and staffing
>transactions as well as organizational planning and development --
>e.g., comparing capabilities of existing human resources against
>those required to execute new or proposed business strategies.
>
>Recently, we have received some inquiries about how our
>competencies spec relates to e-learning standards. For instance:
>
>Competency definitions information model draft (IMS document)
>- http://www.imsproject.org/rcd/index.html
>
>Metadata information model (latest IEEE version, draft in ballot
>process)
>- Info page http://ltsc.ieee.org/wg12/index.html
>- The document itself http://ltsc.ieee.org/doc/wg12/LOM_WD6_3a.pdf
>
>We've had some preliminary discussions with these groups. I
>believe there is consensus that HR-XML's spec is not duplicative
>in purpose with these specs. However, there appears to be some
>opportunities to align the specs. For instance, one idea that
>has been discussed is to modify HR-XML's competency spec so
>it could point to or reference IMS competency definitions or
>IEEE "learning objects."
>
>Does any of this sound related? I'd be happy to add you to our
>competencies mailing list. We're likely to have a conference
>call within the next two weeks to discuss the above
>harmonization work.
>
>Best Regards,
>
>
>Chuck Allen
>Director
>HR-XML Consortium, Inc.
>-----Original Message-----
>From: Rex Brooks [mailto:rexb@starbourne.com]
>Sent: Tuesday, March 12, 2002 11:44 AM
>To: info@hr-xml.org
>Cc: patrick.gannon@oasis-open.org; karl.best@oasis-open.org; 
>scott.mcgrath@oasis-open.org
>Subject: Liaison with OASIS HumanMarkup TC?
>
>
>Dear HR-XML,Patrick, Karl, Scott, et al,
>
>
>To HR-XML.org, I'm sending this again, this time with my recently 
>written StrawMan draft of
>our  OASIS HumanMarkup TC Requirements Document both as a lengthy 
>addition and as an
>attachment for easier reference. It is in text-ony ASCII because 
>when it is finalized we will
>be using XSLT to transform it into XHTML for the official record and 
>for posting to the OASIS
>HumanMarkup TC website. I am doing my best to include your 
>requirements in our work. A
>response would definitely be appreicated.
>
>
>To, Karl, Scott, et al, I am copying this as a way of notifying you 
>all that we are making
>every effort to ensure that our efforts with HumanMarkup are 
>compatible with and
>interoperable with HR-XML, as one of the "most widely accepted 
>standards" to which we refer
>in our Requirements Document. I sent that draft to our mailing lists 
>moments ago.
>
>
>l have left in the references to the recent correspondence which 
>prompted this last week, in
>order to provide context, and I want to point out that I originally 
>sent this message to
>info@hr-xml.org  a week ago, March 5, 2002. This is in the interest 
>of making a record of due
>diligence since we in the HumanMarkup TC have a self-imposed Mach 15 
>deadline for submission
>of requirements from application areas. In pursuit of this I have 
>joined the hr-xml mailing
>list and downloaded all material on their extant specifications.
>
>
>
>
>Dear Colleagues,
>
>
>I would appreciate it if you could direct me/forward this message to 
>whomever I need to
>contact in my effort to discover if there is a need for a Liaison 
>between the OASIS
>HumanMarkup TC, of which I am the Vice Chair, Secretary and 
>Webmaster and the HR-XML
>Consortium.  I am also a member of the OASIS WSIA TC (Web Services 
>for Interactive
>Applications).
>
>
>I am an independent member of OASIS. I have a similar affiliation 
>with the Web 3D Consortium.
>(Imention the latter because they share the characteristic of having 
>a military connection.
>though not one in common, yet.)
>
>
>I believe that there are good reasons why our work ought to be 
>coordinated, and many good
>reasons why we in HumanMarkup need to be up to date with HR-XML 
>specifications and work
>products. HumanMarkup is actually concerned with a much wider and 
>deeper range of human
>information than individual human data, but which is involved 
>tightly with this arena as
>well,
>
>
>Our website:
>
>
>http://www.oasis-open.org/committees/humanmarkup
>
>
>I am specifically asking for a Liaison now for two reasons: 1, we 
>are scheduled to finish
>work on our formal requirements  by the end of March, and we need to 
>make certain that we do
>not create any conflicts between your xml vocabulary and ours; and, 
>2, I have been asked by
>Sandra Swearingen, CCP, of the Air Force Communications Agency 
>Directorate of Architecture
>and Interoperability,  a  member of the WSIA  TC: " Have you done 
>any work on Human
>Resources?"
>
>
>The answer to this is that I have looked at your website in order to 
>determine that there
>were no obvious superficial conflicts in the areas we are concerned 
>with standardizing.
>
>
>This was asked in relation to a pending conference/teleconference 
>that would include AFPC
>(Air Force Personnel Center) in its context. The specific question 
>which was relayed to me
>is: How closely would Human Markup Languages be related to Human 
>Resources? (See excerpt
>below)
>
>
>My answer to that is going to be: We overlap. You are concerned with 
>such things as tracking
>job performance, delivering benefits, etc uniformly or according to 
>a set standard that could
>be interoperable across industries and business enterprises. We 
>overlap in the areas where
>specific individual human identification data is concerned. We 
>overlap in areas where greater
>depth of personalization services that take into account such things 
>as cultural profiles,
>preferential associations and documented online behavior can be used 
>in applications.
>
>
>There are a great many areas which business software developers and 
>web services developers
>will use both of our standards, so they ought to be as well 
>coordinated as possible in terms
>of vocabulary and operational definitions are concerned.
>
>
>I would appreciate a prompt response.
>
>
>Regards,
>Rex Brooks
>OASIS HumanMarkup TC Vice Chair, Secretary, Webmaster
>
>
>
>
>
>(Bulk of message deleted)
>
>
>From: "Savage, Robert (Doc)" <Robert.Savage@GetronicsGov.com>
>To: "Swearingen Sandra Civ AFCA/ITCM" <Sandra.Swearingen@scott.af.mil>
>Cc: "AFCA/ITCM Enterprise Info Mgmt" <AFCA-ITCM@scott.af.mil>,
>        "Carlson Roy Contr AFCA/ITCM" <Roy.Carlson@scott.af.mil>
>
>Sandra,
>
>How closely would Human Markup Languages be related to Human Resources?
>We're looking over the horizon toward Randolph and AFPC as the next
>pillar in the GCSS-AF developmental timeline.
>
>--Doc
>
>  -----Original Message-----
>From:      Swearingen Sandra Civ AFCA/ITCM
>[mailto:Sandra.Swearingen@scott.af.mil]
>Sent:     Monday, March 04, 2002 15:07
>To: Savage, Robert (Doc)
>Cc: AFCA/ITCM Enterprise Info Mgmt; Carlson Roy Contr AFCA/ITCM
>Subject:     RE: Telecon w/John Wunder
>
>Doc
>
>Reference your statement in your message below, "If we can develop a
>good contact, maybe David can invite the HR-XML folks."  Through the
>OASIS Technical Committee on Web Services for Interactive Applications
>(WSIA), I have been established a working relationship with Mr. Rex
>Brooks, who is Vice Chair of the OASIS Human Markup Languages Technical
>Committee.  He gave our group a presentation on human markup languages
>and I believe he would be a good speaker for the Air Force OAGI meeting.
>His contact information follows:
>
>Rex Brooks
>GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>W3Address: http://www.starbourne.com
>Email: rexb@starbourne.com
>Tel: 510-849-2309
>
>Sandra
>
>Ms Sandra Swearingen
>GS-13, Computer Scientist
>HQ AFCA/ITCM
>203 W. Losey St, Room 1100
>Scott AFB, IL 62225-5222
>DSN:  779-6830 (Commercial:  618-229-6830)
>FAX:  DSN 779-5339
>e-mail:  sandra.swearingen@scott.af.mil
>
>
>
>(Bulk of message deleted.)
>
>
>
>HM.REQUIREMENTS
>last updated: 31March 2002
>(this document describes the different requirements for the 
>HumanMarkup specifications)
>---------------------
>
>
>----------------
>ABSTRACT:
>----------------
>This document specifies goals, requirements, and usage scenarios for 
>the for the various
>levels of the Human  Markup Language: HumanML Schemas (in various 
>flavors), Data Models
>(Vocabularies) and others that have not reached formal discussion as 
>of the day this document
>was published.
>
>----------------
>DOCUMENT STATUS:
>----------------
>
>The design of HumanML is an effort to cover a rather large scope of 
>possible applications.
>This Requirements Document, addresses a number of anticipated 
>possible complications that may
>occur in both pre-module and post-module design process of the 
>standard.  This document is
>expected to be modified in the near future and be modularized along 
>with the relative HumanML
>modules that the initiative's Editors will be assigned to build.
>
>Finally, this document is not to be considered as normative. 
>Although it may involve into
>such, the primary purpose is to help the Initiative in its inner workings.
>
>----------------
>TERMINOLOGY:
>----------------
>For the purposes of clarity, we offer these definitions for terms we 
>use in general and which
>may appear in this document but are not specific to this document:
>
>Human Markup Language (compound term with separated words with Upper 
>and Lower case
>characters as shown) = the XML-based computer networking language 
>specification itself and
>all of its associated modules and sub-specifications.
>
>HumanML(compound term with Upper and Lower case characters as shown) 
>= the Human Markup
>Language Specification.
>
>HumanMarkup (compound term with Upper and Lower Case characters as 
>shown) = the collective
>effort to build the Human Markup Language, also used for similar 
>purposes in the name of the
>OASIS HumanMarkup Technical Committee.
>
>The following terminology is used specifically for and throughout 
>this document, without any
>claims of applicability outside it.
>
>"Human"
>
>When enclosed in double quote marks, as above, it is used as a name 
>for what the HumanMarkup
>Initiative aims to encapsulate into HumanML. Used thus, this term 
>transcends reference to any
>single biological entity or to the collective biological species of 
>Homos Sapiens, and is
>inclusive of all self- to species-conscious effort throughout our 
>history to understand
>ourselves and our place in the universe.
>
>"Must"
>When enclosed in double quote marks, as above, this word, means that 
>the requirement item has
>been classified as an absolute requirement.
>
>"Should"
>When enclosed in double quote marks, as above, this word means that 
>it is believed by this
>Technical Committee that the requirement item will prove itself as 
>absolute in the future,
>but has not yet been classified as such and may be overridden by 
>another requirement.
>
>"May"
>When enclosed in double quote marks, as above, this word means that 
>the requirement item can
>become a requirement in the future, but further study is needed.
>
>(Changes in the above are believed by this straw-man author to be 
>reasonably certain of
>inclusion in the final document, and the changes made are 
>clarifications and grammatical
>corrections. As such, they can probably be accepted at this time 
>(3/12/02) as being ready to
>replace the same section in the document that is currently posted on 
>the OASIS HumanMarkup TC
>website.
>
>Below the changes are more problematical, though still the best the 
>author can come up with,
>however the need for reasonable brevity precludes adding arguments 
>for each change. We can
>conduct such discussions online or in our next meetings.)
>
>----------------
>CLASSIFICATION:
>----------------
>Primary and Secondary Schemata (Was: Layers and vocabularies)
>
>This document distinguishes the Basic HumanMarkup Schema as the 
>Primary Schema and subsequent
>"modules " as Secondary Schemata. Primary Schema and Secondary 
>Schemata replace the term
>"layer(s)" for distinguishing between Schemata of a higher or lower 
>domain, with all
>Secondary Schemata as being capable of engendering and containing 
>further modules which can
>be classified as derivative or submodules as appropriate, but which 
>may always be seen as
>existing in the Secondary grouping on an equal footing.
>
>(The following underlined sentence has been deleted since our entire 
>vocabulary exists as a
>whole, and only various sub-groupings or divisions can be seen as 
>modules when included in
>schemata specific to application areas or for specific purposes. For 
>example, the vocabulary
>module is part of the HumanML data layer.  (debatable terminology.) 
>I don't think the Human
>Markup Language can actually have a data layer. We inherit the XML 
>Schema DataTypes, and it
>is the same for all, so we don't have any particular need to define 
>our own subset, we need
>specify only what datatypes we want for specific Elements and Attributes.)
>
>----------------
>EXISTING STANDARDS:
>----------------
>The Internet community is experiencing a proliferation of new 
>technologies. This is causing
>some confusion and overlap among standards.
>
>HumanMarkup standards "must" always be based on the most widely 
>accepted, non-proprietary
>standards available. At this time this is XML, http://www.w3.org/TR/REC-xml
>
>The Human Markup Language "should" not attempt to produce new 
>standards in relation to
>informational subject or topic areas already addressed or covered by 
>the above-referenced
>most widely accepted standards.
>
>HumanML "should"  incorporate and/or provide for interoperabiity 
>with the above-referenced
>most widely accepted standards.
>
>HumanML "should" use the most effective standards, protocols and 
>methodologies available to
>encapsulate what is "Human" in a well formed data wrapper.
>
>----------------
>REQUIREMENTS:
>----------------
>HumanML "must" be open, which means readily available in its whole 
>and its parts without
>recourse to restricted access by any criteria.
>
>HumanML "must" be inon-proprietary, which means that no private 
>ownership may be asserted
>over its whole or its parts and it must also be unencumbered by any 
>pre-existing Intellectual
>Property Rights for its whole or any part of its specifications.
>
>HumanML "must" be public, which means available freely and without 
>any charge added to the
>cost of transmission to anyone by common means such as the World 
>Wide Web or International
>Postal Services.
>
>HumanML "must" be standard, which means that it is uniform in its 
>whole and its parts with
>regard to any and all applications which make use of it.
>
>HumanML " must " be vendor and/or platform neutral.
>
>----------------
>COMPATIBILITY:
>----------------
>HumanML " must " conform to XML syntax and rules.
>
>----------------
>EXTENSIBILITY:
>----------------
>HumanML vocabularies "must" be extensible.
>
>Terseness "should" be preferred.
>
>----------------
>INTERNATIONALIZATION:
>----------------
>Since XML is Unicode, HumanML implementations "must" support this by 
>default and in a
>well-defined syntax. This section will most likely span a "syntax 
>guidelines rule "
>applicable to all HumanML modules for a common syntax definition. 
>(The author of this version
>does not believe that a Requirements Document for an xml vocabulary 
>should make any mention
>of syntax. This is XML-defined, and subspecifications from groups 
>such as this are not a good
>idea. This is outside our scope, again in this author's opinion.)
>
>----------------
>MULTIPLE IMPLEMENTATIONS:
>----------------
>HumanML "should" be a schema independent framework. (The author of 
>this version does not
>understand what this means, so it must be made understandable. What 
>schema "should" HumanML
>be independent of or from?)
>
>HumanML developers "should" have the choice of using HumanML 
>vocabularies as stand alone XML,
>RDF, or other current and future schema implementations depending on 
>the requirements of the
>applications. (The author of this version does not believe that 
>Requirements for a
>specification ought not have anything to say whatsoever about how 
>any developer anywhere at
>any time chooses to employ a specification. Statements of goals 
>belong, in the current
>author's opinion, in mission statements or project tracking 
>documents for the purposes of
>setting goals and checking goals.)
>
>HumanML Schemas "should" clearly be correlated and differentiated 
>from each other.  The
>unique advantages and disadvantages of each Schema implementation 
>should be made explicit for
>developers to determine which implementation to use.
>
>----------------
>MODULARITY
>----------------
>HumanML will be organized into a Primary Base Human Markup Schema 
>and Secondary Human Markup
>Schemata.
>
>The HumanML Primary Base Human Markup Schema "must" include a 
>HumanIdentity Element that is
>compatible with and interoperable with the most widely accepted 
>standards available.
>
>The HumanML Primary Base Human Markup Schema Human "must" include or 
>add the necessary
>Elements and Attributes required to build the Secondary Human Markup Schemata.
>
>The HumanML Secondary Human Markup Schemata will include a Virtual 
>Reality and Aritificial
>Intelligence Schema.
>
>The HumanML Secondary Human Markup Schemata will include a Human 
>Physical Characteristics
>Description Markup Language Schema.
>
>Further officially sanctioned HumanML Secondary Human Markup 
>Schemata will be added as voted
>by the OASIS HumanMarkup Technical Committee.
>
>----------------
>MULTIPLE IMPLEMENTATIONS:
>----------------
>HumanML "should" be a schema independent framework. (The author of 
>this version does not
>understand what this means, so it must be made understandable. What 
>schema "should" HumanML
>be independent of or from?)
>
>HumanML developers "should" have the choice of using HumanML 
>vocabularies as stand alone XML,
>RDF, or other current and future schema implementations depending on 
>the requirements of the
>applications. (The author of this version does not believe that 
>Requirements for a
>specification ought not have anything to say whatsoever about how 
>any developer anywhere at
>any time chooses to employ a specification. Statements of goals 
>belong, in the current
>author's opinion, in mission statements or project tracking 
>documents for the purposes of
>setting goals and checking goals.)
>
>HumanML Schemas "should" clearly be correlated and differentiated 
>from each other.  The
>unique advantages and disadvantages of each Schema implementation 
>should be made explicit for
>developers to determine which implementation to use
>
>----------------
>MULTIPLE IMPLEMENTATIONS:
>----------------
>HumanML "should" be a schema independent framework. (The author of 
>this version does not
>understand what this means, so it must be made understandable. What 
>schema "should" HumanML
>be independent of or from?)
>
>HumanML developers "should" have the choice of using HumanML 
>vocabularies as stand alone XML,
>RDF, or other current and future schema implementations depending on 
>the requirements of the
>applications. (The author of this version does not believe that 
>Requirements for a
>specification ought not have anything to say whatsoever about how 
>any developer anywhere at
>any time chooses to employ a specification. Statements of goals 
>belong, in the current
>author's opinion, in mission statements or project tracking 
>documents for the purposes of
>setting goals and checking goals.)
>
>HumanML Schemata "should" clearly be correlated and differentiated 
>from each other.  The
>unique advantages and disadvantages of each Schema implementation 
>should be made explicit for
>developers to determine which implementation to use
>
>----------------
>TRUST/DIGITAL SIGNATURES:
>----------------
>HumanML, and the HumanMarkup.repository(See note below.) "should" 
>take into account issues of
>trust, digital signatures, and privacy.
>
>(Note: This author does not believe that we should make requirements 
>about any entities that
>are not yet fully included in the scope of HumanML, and the 
>HumanMarkup.repository is such.
>As such, it will need to have its own Requirements Document Process, 
>in this author's
>opinon.)
>
>
>
>
>
>Sincerely,
>Rex Brooks
>OASIS HumanMarkup TC Vice Chair, Secretary and Webmaster
>--
>Rex Brooks
>GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>W3Address: http://www.starbourne.com
>Email: rexb@starbourne.com
>Tel: 510-849-2309
>Fax: By Request


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request