RE: Genuine interoperability & the tower of Babel

Is the UBL group in OASIS in this space too?  As far as I have been able
to figure out they may be more in the business of making a framework to
put such information into -- but it seems to me that the UN/CEFACT work
has something of that flavor, too.  Whether we are talking about
competing or harmonizing frameworks is utterly unclear to me.

-----Original Message-----
From: Anders W. Tell [mailto:opensource@toolsmiths.se] 
Sent: Wednesday, September 24, 2003 5:38 AM
To: www-ws-arch@w3.org
Cc: Ugo Corda
Subject: Re: Genuine interoperability & the tower of Babel



Hi Ugo,

One of the initiatives is the Core Components work done by UN/CEFACT 
Techologies and Methodologies group. 
<http://webster.disa.org/cefact-groups/tmg/> (site is down for the 
moment) See download/general menu for downloadable documents.

This groups work with technology neutral semantic interoperability with 
well defined mappings to EDIFACT and XML.

/anders

Ugo Corda wrote:

>I recently came across an initiative that seems to address this type of

>issues. It's called Universal Data Element Framework (or UDEF - see 
>http://www.udef.org/). According to its Web page, "the objective of the

>UDEF is to provide a means of real-time identification for semantic 
>equivalency, as an attribute to data elements within e-business 
>document and integration formats".
>
>If somebody else knows of similar initiatives, it would be nice to 
>mention them in our document.
>
>Ugo
>
>  
>
>>-----Original Message-----
>>From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
>>Behalf Of Cutler, Roger (RogerCutler)
>>Sent: Monday, September 22, 2003 7:26 PM
>>To: Champion, Mike; Frank McCabe; www-ws-arch@w3.org
>>Subject: RE: Genuine interoperability & the tower of Babel
>>
>>
>>
>>I agree with Mike's answer -- but I also agree with Frank's analysis. 
>>Three or five years ago we sort of thought that the XML bandwagon was 
>>going to solve this by industry-wide efforts to define common formats 
>>for core data.  I know this very well because I wrote various program 
>>plans based on this assumption that I now either live with or modify 
>>accordingly. Whether this did not happen because it is very difficult,

>>or whether it didn't happen because there was no analogy to MS/IBM/BEA

>>to force the process is probably not relevant -- it has not happened.
>>
>>This is a shame, but we must somehow struggle on.
>>
>>So, Frank, granted that this is a problem, and an expensive one, just 
>>what do you propose doing about it?  Weeping, gnashing our teeth and 
>>rending our garments is probably indicated, but once we have done all 
>>that, do you have any other suggestions?
>>
>>I would personally not be very receptive if your suggestions involved 
>>starting over from square one in the WSA.
>>
>>-----Original Message-----
>>From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
>>Sent: Monday, September 22, 2003 9:10 PM
>>To: Frank McCabe; www-ws-arch@w3.org
>>Subject: RE: Genuine interoperability & the tower of Babel
>>
>>
>>
>> 
>>
>>    
>>
>>>-----Original Message-----
>>>From: Frank McCabe [mailto:frankmccabe@mac.com]
>>>Sent: Monday, September 22, 2003 9:40 PM
>>>To: www-ws-arch@w3.org
>>>Subject: Genuine interoperability & the tower of Babel
>>>
>>>      
>>>
>> 
>>    
>>
>>>The tower of Babel referred to above is the huge number of 
>>>application-specific systems that can't leverage each other because 
>>>of trivial but lethal incompatibilities. There has to be a better 
>>>way.
>>>
>>>Before we look at solutions, it is helpful to see that there is a 
>>>problem. Is this analysis off the mark, and if so, why?
>>>      
>>>
>>I'm not sure.  There's a danger in taking things one step at a time if

>>the steps don't lead anywyhere, e.g. climing a tree as the first step 
>>to get to the moon. But there's also a danger in saying that it does 
>>no good to get to the moon if you really really want to reach the 
>>stars.
>>
>>Let's look at the world of 15 years ago vs the world of
>>today, the near
>>term future, and the future we want to shape.  15 years ago a typical
>>computer simply could not communicate with another computer chosen at
>>random, except very inefficiently and with all sorts of human
>>intervention (remember zmodem etc.?). That's because there 
>>was no common
>>wire level protocol or addressing scheme (in widespread use 
>>anyway).  10
>>years ago the Internet solved that problem at the lowest level for at
>>least the typical commercial/university system, but there 
>>wasn't much in
>>the way of common data formats or application-level 
>>protocols.  5 years
>>ago HTTP and HTML solved those problems for human-readable 
>>text, but not
>>for machine-machine interaction without human intervention.  Today XML
>>and SOAP/WSDL are providing the framework for machine-machine
>>interaction, but there are a bazillion details such as transactions,
>>choreography, security, etc. etc. etc. that have to be worked 
>>out in an
>>ad hoc way.  In 5 year we'll presumably have this stuff standardized,
>>BUT THEN we will still face the problems that Frank is 
>>talking about.  
>>
>>So, I think that the WSA document needs to focus on the issues facing 
>>the next few years, and simply make reference to the problems of 
>>automating the semantic alignment of operations and data that will 
>>still be there when the short-term issues are solved.
>>
>>So, there is a problem, but lots of useful work can be done without 
>>solving it, and there are worse problems to solve first. After all, 
>>businesses have been coping with these semantic mismatches for 
>>centuries while the mechanical aspects of business communication have 
>>been improved.  Sure, at some point the mechanical stuff will be
>>nailed down
>>and then the labor-intensive, error-prone approaches used by 
>>application
>>writers to align semantics will be the worst problems that systems
>>integrators face, but there is a lot of work to do before we 
>>are in that
>>situation.
>>
>>
>>
>>
>>    
>>
>
>
>
>  
>

Received on Wednesday, 24 September 2003 10:22:16 UTC