atom feed77 messages in org.oasis-open.lists.regrepRe: [regrep] [TN Proposal] Mapping Bu...
FromSent OnAttachments
11 earlier messages
Fuger, SallySep 17, 2004 12:17 pm 
Farrukh NajmiSep 17, 2004 12:50 pm 
Farrukh NajmiSep 17, 2004 1:03 pm 
Chiusano JosephSep 17, 2004 1:14 pm 
Carl MattocksSep 17, 2004 2:01 pm 
Chiusano JosephSep 17, 2004 2:05 pm 
Farrukh NajmiSep 17, 2004 2:11 pm 
Carl MattocksSep 17, 2004 3:05 pm 
Duane NickullSep 20, 2004 8:48 am 
Duane NickullSep 20, 2004 8:49 am 
Duane NickullSep 20, 2004 8:54 am 
Farrukh NajmiSep 20, 2004 8:56 am 
Farrukh NajmiSep 20, 2004 8:59 am 
Breininger, Kathryn RSep 20, 2004 9:02 am 
Duane NickullSep 20, 2004 9:49 am 
Chiusano JosephSep 20, 2004 10:14 am 
David RR WebberSep 20, 2004 11:13 am 
David RR WebberSep 20, 2004 11:19 am 
David RR WebberSep 20, 2004 11:20 am 
Duane NickullSep 20, 2004 11:37 am 
Duane NickullSep 20, 2004 11:39 am 
Duane NickullSep 20, 2004 11:43 am 
David RR WebberSep 20, 2004 11:43 am 
David RR WebberSep 20, 2004 11:50 am 
David RR WebberSep 20, 2004 11:59 am 
Duane NickullSep 20, 2004 12:03 pm 
Duane NickullSep 20, 2004 12:06 pm 
David RR WebberSep 20, 2004 12:17 pm 
David RR WebberSep 20, 2004 12:26 pm 
Duane NickullSep 20, 2004 12:27 pm 
David RR WebberSep 20, 2004 12:34 pm 
Matthew MacKenzieSep 20, 2004 12:37 pm 
Duane NickullSep 20, 2004 12:58 pm 
Duane NickullSep 20, 2004 1:02 pm 
Farrukh NajmiSep 20, 2004 1:07 pm 
Matthew MacKenzieSep 20, 2004 1:12 pm 
Chiusano JosephSep 20, 2004 1:43 pm 
Matthew MacKenzieSep 20, 2004 1:46 pm 
Duane NickullSep 20, 2004 1:47 pm 
Matthew MacKenzieSep 20, 2004 1:53 pm 
Duane NickullSep 20, 2004 3:19 pm 
Chiusano JosephSep 20, 2004 5:20 pm 
Duane NickullSep 20, 2004 5:49 pm 
David RR WebberSep 20, 2004 6:31 pm 
David RR WebberSep 20, 2004 6:33 pm 
David RR WebberSep 20, 2004 6:35 pm 
Duane NickullSep 20, 2004 7:34 pm 
Matthew MacKenzieSep 20, 2004 7:42 pm 
Matthew MacKenzieSep 20, 2004 7:45 pm 
Duane NickullSep 20, 2004 8:52 pm 
16 later messages
Subject:Re: [regrep] [TN Proposal] Mapping Business Information Models toebXML RegistryInformation Model (Was: [regrep] UN/CEFACT-ICG adopts freebXMLRegistry)
From:David RR Webber (dav@drrw.info)
Date:Sep 20, 2004 11:59:10 am
List:org.oasis-open.lists.regrep

Duane,

OK - the SCM noun is actually engineered the other way around.

It allows you to point to a CC instance using CCTS terminology - such as ABIE, BCC, ACC, and so on - and therefore provide one or more phyical renderings that relate to a high level CCTS object.

But your mechanism also works - where the CC instance can point to a noun instance in the registry. I would suggest you use a LID based interface for this - rather than a UUID based one.

Something like:

<Property type="ebNoun" registry_addressing="http-binding goes here" referenceID="LID_value"/>

Thanks, DW ====================================== Duane Nickull wrote:

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" />

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:

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)

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.

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.