OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] [TN Proposal] Mapping Business Information Models toebXML RegistryInformation Model (Was: [regrep] UN/CEFACT-ICG adopts freebXMLRegistry)




David RR Webber wrote:

> The *last* thing you want to do is try and use the registry to do 
> assembly itself - that's an intractible problem. That is why you have 
> jCAM engines, et al.

You may have misinterpretted my email. I would never advocate that the 
registry does the assembly, just serves up the artifactrs necessary to 
be assembled to something like jCAM or whatever else.

Even jCAM has requirements on what must be present in each artifact it 
assembles.  I would welcome your comments on the CC-Review document as 
to whether or not they appear to appease CAM's needs. 

I did make a format that allows CAM users to place their own information 
into a CC or BIE without affecting other users.  For example, if there 
is a property that only CAM users need, they can have it declared 
wityhin the CC instance:

<Property type="jCAM_user_ID_here" value="UUID:URN:DRRW1001" />

Duane

>
> Instead - you simply model a flat UMM CC structure onto RIM, and 
> optionally extend that with SCM noun instances as needed.
>
> That's it - no more.
>
> Then its up to the backend UML modelling tools to reference that 
> content and do clever things internally as they wish.  They can also
> optionally output CAM template instances as XML - to drive the use of 
> the registry content semantics.
>
> That was the lesson we learned before - keep this very simple - 
> separate the task out into logical parts - semantics, relationships 
> (OWL), assembly;
> do not try and mix those into one hair ball.
>
> DW.
>
> Farrukh Najmi wrote:
>
>> Farrukh Najmi wrote:
>>
>>> Duane Nickull wrote:
>>>
>>>> I would propose that this approach is flawed since CCTS is a 
>>>> special case.  If you read the entire CCTS set of documents AND 
>>>> UMM, you will clearly see a need for more than a simple mapping and 
>>>> storage.  This is documented in my requirements in CC-Review.  CC's 
>>>> and BIE's need to serialize the information and carry it to 
>>>> persistent stores outside the registry. That places a requirement 
>>>> of duplication of certain RIM instance data in the CC instance, so 
>>>> it can be used without a registry system present in the way that 
>>>> UMM dictates Business information entities be used.
>>>
>>>
>>>
>> The requirement you mentions as special (the need to duplicate 
>> content into metadata) is actually very common based on my 
>> experience. Our proposed TN would address this pattern explicitly 
>> using the Content Cataloging feature.
>>
>> What am I missing?
>>
>>>
>>> A few special cases in CCTS mapping do not obviate the need for a 
>>> generic mapping TN that covers most domain specific mapping and 90%+ 
>>> of CCTS.
>>> What is the downside of doing a generic mapping document as you see it?
>>>
>>>>
>>>> Duane
>>>>
>>>> Carl Mattocks wrote:
>>>>
>>>>> Mapping Domain Patterns in ISO/TS 15000 Registry Information Model
>>>>> should be of interest to those who need to take a risk free approach
>>>>>
>>>>> <quote who="Chiusano Joseph">
>>>>>  
>>>>>
>>>>>> Excellent idea. I recall mention of this during the earlier 
>>>>>> CC-RIM in
>>>>>> summer 2003.
>>>>>>
>>>>>> Regarding the title: Perhaps can do something with the word 
>>>>>> "Business",
>>>>>> as it seems to convey that the TN would cover only information at a
>>>>>> higher layer, and I don't think we would much care what the
>>>>>> meaning/intent of the information was. Perhaps we could:
>>>>>>
>>>>>> (1) Drop the word "Business" (becomes "Mapping Information 
>>>>>> Models...")
>>>>>> (2) Supplement it ("Mapping Business and Domain Specific Information
>>>>>> Models..."), or
>>>>>> (3) Substitute it (no particular word comes to mind right now)
>>>>>>
>>>>>> Joe
>>>>>>
>>>>>> Farrukh Najmi wrote:
>>>>>>  
>>>>>>
>>>>>>> Yet another important thing I did not mention is that as we were
>>>>>>> discussing the
>>>>>>> mapping from CCTS UML Model to ebRIM UML model I suggested that the
>>>>>>> registry TC
>>>>>>> should create a TN titledsomething like:
>>>>>>>
>>>>>>> "Mapping Business Information Models to ebXML Registry Information
>>>>>>> Model"
>>>>>>>
>>>>>>> This TN would provide the generic patterns and algorithms for 
>>>>>>> mapping
>>>>>>> any
>>>>>>> Business or Domain specific information model to ebRIM.
>>>>>>>
>>>>>>> This is an idea that Nikola had come up with a long time ago. As I
>>>>>>> recall he had
>>>>>>> even made a list of such patterns at some point.
>>>>>>>
>>>>>>> As more and more domains are adopting ebXML Registry standard 
>>>>>>> they are
>>>>>>> faced
>>>>>>> with the recurring need to map between their info model and ebRIM.
>>>>>>> Currently
>>>>>>> this is being done ad hoc. With the proposed TN this recurring 
>>>>>>> need will
>>>>>>> be
>>>>>>> nicely addressed.
>>>>>>>
>>>>>>> I view the proposed TN to be very valuable indeed to the ebXML 
>>>>>>> Registry
>>>>>>> user
>>>>>>> community. I expect the paper to be relatively brief.
>>>>>>>
>>>>>>> I have spoken to Nikola about resurrecting his work in this area 
>>>>>>> and he
>>>>>>> graciously agreed. During the course of next week Nikola and I will
>>>>>>> collaborate
>>>>>>> to put an initial draft of the proposed TN for the teams review.
>>>>>>>
>>>>>>> Thanks in advance for sharing any thoughts on this idea and 
>>>>>>> specially on
>>>>>>> the
>>>>>>> title of the note.
>>>>>>>
>>>>>>> -- 
>>>>>>> Regards,
>>>>>>> Farrukh
>>>>>>>
>>>>>>> Farrukh Najmi wrote:
>>>>>>>
>>>>>>>  
>>>>>>>
>>>>>>>> The UN/CEFACT Information Content Management Group (ICG) has
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> officially
>>>>>>>  
>>>>>>>
>>>>>>>> adopted the ebXML Registry standard as the center
>>>>>>>> piece of their new Information Content Management Architecture.
>>>>>>>>
>>>>>>>> The architecture will be implemented as a federation of autonomous
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ebXML
>>>>>>>  
>>>>>>>
>>>>>>>> Registries operated by various UN/CEFACT members countries and
>>>>>>>> organization. They are also envisioning a top level UN/CEFACT 
>>>>>>>> ebXML
>>>>>>>> Registry as the leader of the registry federation. The UN registry
>>>>>>>> federation will store Core Component artifacts as well as many 
>>>>>>>> other
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> UN
>>>>>>>  
>>>>>>>
>>>>>>>> defined artifacts.
>>>>>>>>
>>>>>>>> At ICG invitation I attended a two day meeting Thursday and 
>>>>>>>> Friday.
>>>>>>>> On Thursday I presented ebXML Registry standard to them and 
>>>>>>>> discussed
>>>>>>>> their requirements and how ebXML Registry standard met those
>>>>>>>> requirements. On Friday we developed the blueprint for their
>>>>>>>> ebXML Registry based architecture which was then presented to the
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> broader
>>>>>>>  
>>>>>>>
>>>>>>>> participant of the UN/CEFACT conference.
>>>>>>>>
>>>>>>>> It was good to see David Webber in the audience who contributed to
>>>>>>>> the lively discussion. The presentation was well received.
>>>>>>>>
>>>>>>>> I will send link to the UN/CEFACT Information Content Management
>>>>>>>> Architecture slides as soon as it gets posted on their web site:
>>>>>>>>
>>>>>>>>   http://www.disa.org/cefact-groups/icg/
>>>>>>>>
>>>>>>>> All in all I am overwhelmed by the success of this meeting and 
>>>>>>>> hope
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> that
>>>>>>>  
>>>>>>>
>>>>>>>> this momentum in the adoption of the ebXML Registry standard 
>>>>>>>> continues
>>>>>>>> to escalate.
>>>>>>>>
>>>>>>>> We as a team should feel very proud of the success of our 
>>>>>>>> standard.
>>>>>>>>
>>>>>>>>       
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>>>> roster of
>>>>>>> the
>>>>>>> OASIS TC), go to
>>>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>>>
>>>>>>>
>>>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>>>> roster of
>>>>>>> the OASIS TC), go to
>>>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>>>
>>>>>>>     
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Kind Regards,
>>>>>> Joseph Chiusano
>>>>>> Associate
>>>>>> Booz Allen Hamilton
>>>>>>
>>>>>> To unsubscribe from this mailing list (and be removed from the 
>>>>>> roster of
>>>>>> the OASIS TC), go to
>>>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>>>
>>>>>>
>>>>>>
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>
>>>> To unsubscribe from this mailing list (and be removed from the 
>>>> roster of the OASIS TC), go to 
>>>> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php. 
>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]