[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
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. ======================================================================
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]