[humanmarkup] Fwd: RE: Liaison with OASIS HumanMarkup TC?

[Rex Brooks <rexb@starbourne.com>]

I am forwarding this to let you all know that I am taking Chuck Allen 
up on his offer to join the "Competencies" mailing list and I will 
let you know of interesting developments as they relate to developing 
the Human Markup Language.

Ciao,
Rex

>X-From_: chucka@hr-xml.org  Tue Mar 12 10:04:12 2002
>Reply-To: <chucka@hr-xml.org>
>From: "Chuck Allen - HR-XML" <chucka@hr-xml.org>
>To: "Rex Brooks" <rexb@starbourne.com>
>Cc: <patrick.gannon@oasis-open.org>, <karl.best@oasis-open.org>,
>    <scott.mcgrath@oasis-open.org>
>Subject: RE: Liaison with OASIS HumanMarkup TC?
>Date: Tue, 12 Mar 2002 13:14:25 -0500
>X-Priority: 3 (Normal)
>Importance: Normal
>
>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