13 Mar. Conf Call followup: BP Reqmts

[Bob Haugen <linkage@interaccess.com>]

One of the topics in the conference call was (loosely)
what are the requirements for the BP metamodel?
Or more generally what are the requirements for
the BP group?

Here are some selections from the ebXML Requirements
Specification V 0.50 that may suggest either overlapping
requirements among groups, or requirements from other
groups for BP deliverables.  Some email excerpts follow,
along the same theme.

<comment>
my comment
</comment>

<requirements selections>
3.3  Business Process
The Business Process Project Team detailed requirements and deliverables 
will: -
* Provide a high-level business process methodology in terms of XML, e.g., 
DTD.

<comment>
My understanding was that "methodology" had been removed from the
group's name and goals, and that "business process model" was the
revised goal.  Is this true?
</comment>

* Select a methodology with which to specify "vertical" business processes 
according to a uniform "template" (i.e., ebXML "superset") to support 
comparison.
* Explicitly specify the ebXML "superset" business process meta-model. In 
no instance shall this meta-model be subject to implied specification using 
instantiations or derivations.

<comment>
Mike Rawlins wrote:
> there may still be some sections that have overly detailed,
> technical terms and jargon.  Things like "In no instance shall this
> meta-model be subject to implied specification using instantiations or
> derivations" come to mind
</comment>

* Incorporate cross-industry methodologies for specifying business 
processes, e.g., Open Applications Group (OAG), RosettaNet, Health Level 
Seven (HL7), into the ebXML "superset."
* Specify reusable objects.
* Create  a glossary of terms related to business process methodology: 
vocabulary,- e.g., such as functional, non-functional, vertical, message, 
segment, data type- shall be created and maintained using UN/CEFACT TMWG 
Unified Modeling Methodology document Annex 1 as a start.
* Create a glossary of terms specific to each business process to be 
modeled.
* Create a glossary of XML tags.
* Support language neutral mechanisms for associating business vocabularies 
to repository semantic definitions.
* Be developed in conjunction with the Registry and Repository Project Team 
to incorporate technical specifications, models, and required glossaries 
into the ebXML repository.

2.5.1 Architecture
* Common Business Processes - Both entities involved in the exchange of 
data must be engaged in executing the same transaction in the context of a 
business process.
* Common Semantics - Common meaning, as distinct from words, expression, or 
presentation.

3.4 Technical Architecture Project Team
* Provide and support a library of common, standard intra-business 
processes

3.5 Core Components
* Identify a methodology for describing core components

3.7        Registry and Repository
* a glossary of terms related to business process methodology: vocabulary 
(e.g., functional, non-functional, vertical, message, segment, data type 
 using TMWG Unified Modeling Methodology document Annex 1)
* a glossary of terms specific to each business process to be modeled
</requirements selections>

<email excerpts>
Here are some excerpts from emails that suggest other overlaps
or cross-group requirements:
Scott Neiman wrote:
| I could search across all DataElementName values for *Purchase* 
(wildcard=*)
| and find a boatload of definitions and associated information.

Terry Allen replied:
>That would be a Bad Idea because you'd be relying on naming conventions.
>What you want to is search for data elements that are somehow related to
>the "Purchase" taxon in some classification scheme.

>From another email by Terry Allen:
>the set of related data may not be the same as the distribution.
>It's more like a node in a taxonomy (or other classification)
>of DTDs.  We can make this something abstract (that is, not
>any of the registered items).  It would correspond to the notion
>of a literary work:  the Bible is a literary work with
>many versions and physical instantiations, none of which is
>primary in the way a book's first edition can be.  Robin, is
>this what you have in mind?

>We might instantiate this notion as the name of an item in
>a classification scheme, so that "Docbook DTD" would be such
>an item.  Note that this classification scheme would not be
>the same as the subject matter classification scheme we know
>we need.
</email excerpts>

<comment>
My point here is not to suggest which group should do what;
it is that there are several groups with metadata or classification
or glossary or metamodel or process model requirements
that (at least) should be mutually consistent.
</comment>

Make sense?
Bob Haugen