[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure2-1
I think we'll need to be specific about the relationships, then. Rex At 7:27 AM -0700 5/19/05, Duane Nickull wrote: >Rex: > >Sadly, I do not think there are any normative mind maps reference >models. There is some text on interpreting concept maps in the W3C >WSA. This is an observation. If we decide to use this, we may wish >to write a small blurb on interpreting them to avoid ambiguity. > >Matt and I also wrote the last chapter of our position paper as a >guide to interpret concept maps. >Duane > >Rex Brooks wrote: > >>Duane, >> >>Do you have a specific url for a guide to Mind Maps? >> >>Ciao, >>Rex >> >>At 6:49 AM -0700 5/19/05, Duane Nickull wrote: >> >>>Gregory et al: >>> >>>In mind maps, arrows are often used by convention to denote >>>unilateral labelled associations. Removing them creates a >>>bilateral labelled association. It does not indicate process. >>> >>>Duane >>> >>>Gregory A. Kohring wrote: >>> >>>>Here is a new draft of figure 2-1 incorporating all the suggested >>>>changes to date. Let's use this as the basis for further discussions. >>>> >>>>-- Greg >>>> >>>> >>>>Peter F Brown wrote: >>>> >>>>>Greg: >>>>>Sounds better, I agree and would be happy to keep that >>>>>definition. I'd still >>>>>like to see some other reactions (we might have to wait until the Americas >>>>>awake...) to my other point though: should this aspect be in the >>>>>RM at all, >>>>>or are metadata (or other "free text" policies or service descriptions, >>>>>etc.) only part of specific and/or reference *architectures* >>>>>rather than the >>>>>RM? >>>>> >>>>>-Peter >>>>>-----Original Message----- >>>>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] Sent: 19 >>>>>May 2005 11:04 >>>>>To: peter@justbrown.net >>>>>Cc: 'SOA-RM' >>>>>Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line 201, Figure >>>>>2-1 >>>>> >>>>>Yes "realized as" is not the right phrase here. Would you support >>>>>"documented in"? >>>>> >>>>>-- Greg >>>>> >>>>> >>>>>Peter F Brown wrote: >>>>> >>>>> >>>>>>I like this diagram more. I think it's closer to my >>>>>>understanding at least of wherewe want to go. >>>>>> >>>>>>My only question is: are the semantics *only* realised as >>>>>>metadata? Or more >>>>>>precisely: in a Reference Model, are the semantics of the >>>>>>service realised at all? Surely the metadata "realisation" is >>>>>>part of a reference architecture not a reference model? >>>>>> >>>>>>-Peter >>>>>> >>>>>>-----Original Message----- >>>>>>From: Gregory A. Kohring [mailto:kohring@ccrl-nece.de] >>>>>>Sent: 19 May 2005 09:24 >>>>>>To: Francis McCabe >>>>>>Cc: SOA-RM; dnickull@adobe.com; mattm@adobe.com >>>>>>Subject: Re: [soa-rm] [issue:structure] draft 07, sect 2, line >>>>>>201, Figure >>>>>>2-1 >>>>>> >>>>>>Frank, >>>>>> >>>>>>If I understand you correctly, then in your view there is >>>>>>little to be gained by distinguishing between syntaxt and >>>>>>semantics at this level. >>>>>>Hence, the "Service Description" is purely semantics. >>>>>> >>>>>>Attached is another diagram which depicts this idea. Is this >>>>>>consistent with your ideas? >>>>>> >>>>>>-- Greg >>>>>> >>>>>>Francis McCabe wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>While I like the direction in which this is going, I have a couple of >>>>>>>issues: >>>>>>> >>>>>>>1. I do not see semantics as being inside service description. >>>>>>>Semantics is an abstract concept that may be referred to but >>>>>>>is not contained in any description. >>>>>>>2. I am not sure why data model is broken out in the way >>>>>>>suggested. To me, tehe data model is an asepct of the >>>>>>>semantics of the service. >>>>>>>3. I do not see a hard and fast distinction between syntax and >>>>>>>semantics. Again, any syntactic constraints are simply part of >>>>>>>the overall semantics. >>>>>>> >>>>>>>The *reason* for this is that while it is tempting to equate >>>>>>>semantics with application semantics, that is not, in fact, a >>>>>>>good slope to slip down. >>>>>>> >>>>>>>Once you liberate yourself from that misconception, one beings >>>>>>>to see all kinds of possibilities. For example, for an >>>>>>>encryption/decryption service, its entire semantic model >>>>>>>consists of messages with encryption markers etc. etc. Is that >>>>>>>syntax? Depends on your point of view; to my mind it is >>>>>>>semantics of a simple service. >>>>>>> >>>>>>> >>>>>>>Frank >>>>>>> >>>>>>> >>>>>>>On May 13, 2005, at 12:01 AM, Gregory A. Kohring wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Yes, this looks much better. Attached is a slight variation >>>>>>>>which moves the semantics into the description. At one time, >>>>>>>>"syntax" was also explicitly mentioned as being part of the >>>>>>>>description. Has that been dropped? >>>>>>>> >>>>>>>>-- Greg >>>>>>>> >>>>>>>>Duane Nickull wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Does something like this make more sense than a stack >>>>>>>>>diagram. This is >>>>>>>>>uses a multi-layered approach to group things and reduce the >>>>>>>>>number of lines. >>>>>>>>> >>>>>>>>>Duane >>>>>>>>> >>>>>>>>>Duane Nickull wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>>The issue we had with the concept map is we ended up with a >>>>>>>>>>proliferation of arrows for items like "semantics" and >>>>>>>>>>security since >>>>>>>>>>they are omni-present. We tried various other depictions >>>>>>>>>>and finally >>>>>>>>>>came to the stack. I agree that the stack alone is not >>>>>>>>>>sufficient and also lends itself to ambiguity so we agreed >>>>>>>>>>to place some text by >>>>>>>>>> >>>>>>>>> >>>>>>it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>>>There are standard conventions for interpreting stack >>>>>>>>>>diagrams. For example - layers in the stack are only able >>>>>>>>>>to talk to adjacent layers. Layer n can interact with n-1 >>>>>>>>>>and n+1, but not n+2. >>>>>>>>>> >>>>>>>>>>The position of the vertical layers indicate they are >>>>>>>>>>relevant to each horizontal layer they are adjacent to. >>>>>>>>>> >>>>>>>>>>In stack diagrams, there is no named associations present >>>>>>>>>>so it is ambiguous. >>>>>>>>>> >>>>>>>>>>Accordingly, one can infer the following from the diagram in 2.1 >>>>>>>>>> >>>>>>>>>>Service descriptions (are associated with) services >>>>>>>>>>Policies (are associated with) service descriptions >>>>>>>>>>Contracts (are associated >>>>>>>>>>with) policies data models (are associated with) contracts >>>>>>>>>>semantics (are associated with) service descriptions, >>>>>>>>>>policies, contracts and data models. >>>>>>>>>>Services, Service descriptions, policies, contracts and >>>>>>>>>>data models may all be discoverable and their presence and >>>>>>>>>>availability known. >>>>>>>>>> >>>>>>>>>>What I do not like is that it also separates the data model >>>>>>>>>>from the service description and separates the contract >>>>>>>>>>from the service description. >>>>>>>>>> >>>>>>>>>>It may be better to go with a layered concept map. >>>>>>>>>>Duane >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>> >>>> >>>> >>>> >>>>------------------------------------------------------------------------ -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]