[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, Figure 2-1
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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]