Re: SPAM-LOW: Re: Hardin (ebBP) 3/7/2005: Conversations in the contextof ebBP-CPA-ebMS

[john c hardin <john@crossconnections.ws>]

Thanks for the feedback, Monica - I finally joined the ebBP group, and 
will be on the call today.

What I was referring to was a wider issue that the overall architecture 
of an SOA-like, cross-industry framework needs to address. That being, 
the data element semantics in the actual business documents, which is 
what I believe you are referring to by illustrating the "references to 
semantic information that provides (loosely) a context to the business 
information".

There should a pattern in the architecture for patterns that allows for 
'semantic resolution' between two formats. Mechanisms providing semantic 
analysis, mapping code generation and finally, transformation between 
two or more formats that were mapped, needs to be much more automated. 
Contivo does an excellent job of this, with a drawback: the enterprise 
vocabularies are described in - you guessed it - english. This works 
well for enterprise semantic metadata repositories. However, a numeric 
format (CCTS) or alphanumeric format (UDEF) needs to be used in the 
global framework.

CPA should reference the semantic metadata entry (maybe Schema, could be 
other however) in the registry that contains the semantic identification 
information for each element, and the BP execution should link to the 
transformation mechanism. Without human intervention. In english. ; >

By the way, the UDEF has been picked up by the Open Group as the 
potential host for the data element trees:

http://www.opengroup.org/projects/udef/protected/

Let's remove the human mapping activity, eventually. Comments?

 >
 > English please...let's look at this simply.  The key is to provide
 > a mapping that begins with semantic understanding. For example, ebBP
 > allows references to semantic information that provides (loosely) a
 > context to the business information provided. The semantic (and
 > syntactic) understanding between the specifications is that they can
 > effectively use (at their level of intelligence) basic constructs and
 > patterns between them. For example, ebBP provides a process
 > specification, roles and relationships and activities associated with
 > both.  CPA and ebMS takes that 'context' and uses them at the level it
 > operates. This is semantic understanding. Of course there is more work
 > to go (and we all acknowledge it). Your turn. Thanks.
 >



Monica J. Martin wrote:
> john c hardin wrote:
> 
>> Yes, absolutely. Actually today and all week, I am making notes for 
>> submission to the group re: the next steps to take with the Technical 
>> Architecture document.
>>
>> The link between the Reg-MS-CAP-BP execution layers is very crucial 
>> for the next generation of completely distributed, loosely-coupled 
>> apps. Public / Private processes are targeted for my personal goals. I 
>> want to enable the entire network, with interlocking, but independent 
>> processes.
>>
>> The two missing items, from my understanding, are the ubiquitous 
>> semantic identifiers in all formats, and the event causality / event 
>> monitoring handles capable of deciphering the undoubtedly complex 
>> layers of events, firing events, firing OTHER events, which in turn 
>> are used as decision points that fire yet more events, ad nauseum...
>>
>> Monica, what are your thoughts on this last part?
>>
> 
> 
> 
>