[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
While this is more accurate, it is verging on being too concrete, though I would certainly allow it (Remember my initial position was to start from scenarios and use-cases and abstract upwards rather than model top-down as we are doing). Ciao, Rex At 9:39 AM +0200 5/20/05, Gregory A. Kohring wrote: >Duane, > >I agree that metadata has semantics, but in this case we are >interested in the semantics of the service, not the metadata. >Any diagram of this type will get too crowed if we have to >explicitly depict every possible relationship; therefore, we >need to restrict ourselves to the most important relationships. > >I think we now agree that metadata "documents" or "describes" the >semantics; however, a related question is >whether or not the documented metadata, as opposed to the semantics, >"enables discoverability". In other words, if semantics is ubiquitous >as you say, then semantics cannot by itself enable discoverability >(if it could then everything would already be discoverable), >rather it is the documentation of the semantics which >enables discoverability. > >Following this line of thought, I would propose the attached diagram. > >-- Greg > >Duane Nickull wrote: >> Semantics are ubiquitous. No matter if they are explicit or implicit, >> they are present. >> Meta data has semantics. >> Metadata is a set of data declaring details pertaining to another set of >> data. >> I am not convinced that semantics are realized as metadata. In fact, in >> a reference model, nothing is realized - it is all abstract. >> >> Duane >> >> >> Gregory A. Kohring wrote: >> >>> 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 >>>>>>>> >>>>>>>> >>> >>> >>> >>> >> > > >-- >====================================================================== >G.A. Kohring >C&C Research Laboratories, NEC Europe Ltd. >====================================================================== > >Attachment converted: Macintosh HD:figure1a.png (PNGf/«IC») (0006807C) -- 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]