RE: 16 Mar. Conference Call notice

[Christian Huemer <ch@ifs.univie.ac.at>]

> Christian, do you think the metamodel be independent of the business
> domain?  In other words, are you proposing a "process metamodel"
> independent of business?
> 

yes, i think that the meta model is independent of the business domain.
the class diagramm part of a meta model reflects the artifacts of 
"inter-organizational" business process modeling. so the background
is "business modeling" but it is not specific to a certain business.

btw, un/cefact tmwg takes the position that a meta model should not
only cover class diagramms, but also activity diagrams. in other words,
this means that there should be common methodology ...


> If so, maybe I am in the wrong group and you are correct,
> I should be focusing on core components.
> 
> But core components right now is focused on relatively
> small and relatively standalone components.  There are
> much larger more process-like re-usable things-of-some-type
> that are embedded in every one of the eight business metamodel
> candidates in the ebXML-BP list.  This is the level that I am
> interested in - not a very abstract process metametamodel
> that does not get down to the level of business in any sense.
> 

tmwg feels that core components should go into the direction
of modeling. they should define patterns and utility classes for
the purpose of reuse. and i agree that reuse can apply to any
level of detail and to different modelling concepts (classes, 
activities, ...). what we need is to provide a concept for reusability.

tmwg would highly appriciate people with detailed modeling knowledge
to join core components.

> Do you think that ebXML should not deal with that level
> in any group?
> 

ebxml by itself should not provide a solution for a specific domain.
ebxml should encourage people working in a certain domain (standard bodies,
software solution providers) to follow the concepts of ebxml. this means
that they should deliver the business domain descriptions in a way
that they can be stored in a repository. so they have to be conform
to the meta model. furthermore, the solutions should use ebxml identified
patterns. the solutions should follow the rules of extensibility of
already registered components, and so on ...

but, i think it is highly desireable if ebxml solutions a created in
parallel with the ebxml initiative. 

> If you are not proposing a totally abstract process metamodel
> with no business content, could you please give an example
> or in some other way clue me in to what you are thinking of?
> 

i think - in your sense - i am proposing something "abstract" :-)
but i think we need a common layer at a higher level to ensure
reuse between different verticals.

christian