[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Metadata
Steve, Please understand that this comment is not directed at you. It is just that this particular message finally rang the bell loud enough for me to respond. Basically, this is about acronyms and the fact that our OASIS process is open to the public, and the public is not likely to understand, as a matter of course for anyone even remotely interested in SOA, that SLA means Service Level Agreement. We live in a world of alphabet soup and I just gave a presentation based on my personal experience in a variety of OASIS technical committees to the Collaborative Expedition Workshop #44 http://colab.cim3.net/cgi-bin/wiki.pl?ExpeditionWorkshop/PioneeringGovernanceMechanisms_TowardMissionDeliveryNetworkedWorld_2005_09_23 and I was not alone in pointing out that our constituencies speak their own, often specialized "languages." At the same time, while we insist on being open to the public for all the good and right reasons, we seldom remember that the public usually isn't conversant with our languages and the alphabet soup syndrome is just one aspect of this tendency. For myself, because I write for a variety of audiences, I try to school myself to always spell out the first usage of an acronym, no matter where I am writing about it, including, and especially in narrow-focus mailing lists such as this. I include the acronym itself, in parentheses, immediately following the spelled out antecedent, such as reminding us all that Three Letter Acronyms (TLAs) often have numerous antecedents. One other antecedent, in this case, is Temporal Logic of Actions (TLA-1). I distinguish between the specific antecedents by the TLA version specified in the parentheses. It is not all that much help to the reader who is unfamiliar with a given antecedent for a given TLA, but it should provide a means to show the difference between a TLA and a TLA-1. I highlighted that I try, since I am just as prone to forgetting this little nicety for our less technical audiences as anyone else. After all, I usually know what I'm referring to... usually... :-[ Ciao, Rex At 11:57 AM +0100 9/28/05, Jones, Steve G wrote: >Line 28, top of page 2 > >"This Reference Model scopes itself to the field of software architecture" > >On my list too J > >I'd like to see us also include services that are provided by >non-technology means, the reason for that is it makes models more >complete and also helps when turning something from manual into >automated as you've already identified it as a service (e.g. paper >based timesheet "service" is replaced by desktop application, SLA >remains the same but the interface has changed). > >Steve > > > >From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] >Sent: 28 September 2005 11:51 >To: soa-rm@lists.oasis-open.org >Subject: RE: [soa-rm] Metadata > >I'm not certain that we state in our RM that "SOA is purely a >software thing" - if we do, I will probably be logging an issue that >that statement be removed or refined. I believe what we say is that >we are *focusing* on the software architecture aspects of SOA. > >Having said that, I believe SOA is much more than software - it is >about *capabilities* that are partially (and greatly) >provided/supported by technical services (I use "technical" rather >than "software" because it sounds more general to me and more >correct when speaking at this level). SOA, in general, can >definitely involve people - consider a supply chain capability that >contains a (sub-)capability for processing purchase orders that is >service-oriented (a "service-oriented capability"). That >sub-capability can be supported by one or more technical services - >for example, a "purchase order service" that enables such >"operations" as "submit PO", "check PO status", "add line item to >PO", etc. > >So it's about technology supporting capabilities that also involve >people. Or put another way, technology supporting capabilities that >support people. > >Joe > > >From: Jones, Steve G [mailto:steve.g.jones@capgemini.com] >Sent: Wed 9/28/2005 4:47 AM >To: Frank McCabe; Ken Laskey >Cc: SOA-RM >Subject: RE: [soa-rm] Metadata > >I'm writing up my review notes at the moment. But this for me is a key area >as to whether SOA is purely a software thing (as stated in the RM) or a >wider architectural approach. The example of the plug-socket I think is a >great example of a physical world SOA, but again there is no technology >(except some complex PAT) that can understand the concept of a plug-socket >and obtain power. The discovery is done by individuals in the same way as >people use ATMs. > >So the question is whether, like Soylent Green, SOA contains people. > >Steve > > >> -----Original Message----- >> From: Frank McCabe >>[<mailto:frank.mccabe@us.fujitsu.com>mailto:frank.mccabe@us.fujitsu.com] >> Sent: 27 September 2005 19:21 >> To: Ken Laskey >> Cc: SOA-RM >> Subject: Re: [soa-rm] Metadata >> > >> Getting slightly back on topic .. :) >> The point of bringing out the machine processability aspect is that >> that *is* the intention behind the descriptions of services. An >> example of a deeply unprocessable description is "this service will >> do wonders for your X life". >> Even assuming that you can parse such descriptions, there is no >> foreseable technology that can use such a description to do discovery >> for instance. >> Frank >> > >> On Sep 27, 2005, at 11:09 AM, Ken Laskey wrote: >> > >> > Today we'll take on the deep meanings of SOA and tomorrow we can >> > deal with the logic of negation. >> > >> > Ken >> > >> > On Sep 27, 2005, at 2:05 PM, Chiusano Joseph wrote: >> > >> > >> >> >> >> I take that double negative as meaning that he is convinced that >> >> it *is* redundant. >> >> >> >> Joe :p >> >> >> >> Joseph Chiusano >> >> Booz Allen Hamilton >> >> >> > >> > >> >> >> >> >> >> 700 13th St. NW >> >> Washington, DC 20005 >> >> O: 202-508-6514 <= new office number as of 09/19/05 >> >> C: 202-251-0731 >> >> Visit us online@ <http://www.boozallen.com>http://www.boozallen.com >> >> >> >> >> >> >> >>> From: Matt MacKenzie [<mailto:mattm@adobe.com>mailto:mattm@adobe.com] >> >>> Sent: Tuesday, September 27, 2005 2:00 PM >> >>> To: Ken Laskey >> >>> Cc: SOA-RM >> >>> Subject: RE: [soa-rm] Metadata >> >>> >> >>> I'm still not convinced that it is not redundant, even with your >> >>> great description. >> >>> >> >>> -matt >> >>> >> >>> >> >>> From: Ken Laskey [<mailto:klaskey@mitre.org>mailto:klaskey@mitre.org] >> >>> Sent: Tuesday, September 27, 2005 1:56 PM >> >>> To: Matt MacKenzie >> >>> Cc: SOA-RM >> >>> Subject: Re: [soa-rm] Metadata >> >>> >> >>> OK, Matt, then I'll attempt to define machine processibility as >> >>> the representation of information in a standard, referenceable >> >>> format that conveys the necessary semantics to enable a machine >> >>> to fully utilize the information for the purpose for which the >> >>> information was created. General use in a context outside its >> >>> original intent may require additional capabilities which are >> >>> outside the current scope of the discussion. >> >>> >> >>> Ken >> >>> >> >>> P.S. Note, I have not taken a position on whether this is within >> >>> RM scope or not. >> >>> >> >>> On Sep 27, 2005, at 1:46 PM, Matt MacKenzie wrote: >> >>> >> >>>> >> >>>> "machine processibility" means nothing. I vote we remove it on >> >>>> that basis. People have been equating machine processability >> >>>> with XML as a way of promoting the XML revolution. The nasty >> >>>> secret is that we were processing reams of information before >> >>>> XML as well. We can build parsers for nearly any language. >> >>>> >> >>>> Lets just remove it. >> >>>> >> >>>> -matt >> >>>> >> >>>> From: Ken Laskey [<mailto:klaskey@mitre.org>mailto:klaskey@mitre.org] >> >>>> Sent: Tuesday, September 27, 2005 1:41 PM >> >>>> To: Duane Nickull; Behera, Prasanta; SOA-RM >> >>>> Subject: RE: [soa-rm] Metadata >> >>>> >> >>>> Duane, >> >>>> >> >>>> This is also somewhat subtle. Is the (desired or realizable) >> >>>> machine processibility of the metadata a fundamental concept or >> >>>> is it a nice to have option for the implementer? The former >> >>>> belongs in the RM, the latter does not. > > >>>> >> >>>> Do log it but also continue to discuss. >> >>>> >> >>>> Ken >> >>>> >> >>>> At 01:16 PM 9/27/2005, Duane Nickull wrote: >> >>>> >> >>>> I would assert that since our model is abstract, the adjective >> >>>> "machine process-able" is overstepping the bounds and scope of >> >>>> the spec. As soon as we say this we are being too concrete. It >> >>>> is equally feasible that a half automated system will rely on >> >>>> some human to look at *some* aspects of a services metadata such >> >>>> as who the owner is or something to assure them it is secure. >> >>>> >> >>>> Recommend we log it as an issue and propose the machine process- >> >>>> able part be removed. >> >>>> >> >>>> Duane >> >>>> >> >>>> >> >>>> From: Behera, Prasanta [ >><mailto:pbehera@visa.com>mailto:pbehera@visa.com] >> >>>> Sent: Tuesday, September 27, 2005 9:44 AM >> >>>> To: SOA-RM >> >>>> Subject: [soa-rm] Metadata >> >>>> >> >>>> >> >>>> Is metadata == "machine process-able descriptions"? >> >>>> >> >>>> In the 09 draft (section 2.2.3), it seems that we are making >> >>>> that assertion. >> >>>> >> >>>> I think "machine process-able description/information" is a >> >>>> component of it. >> >>>> >> >>>> >> >>>> Opinion/thought? >> >>>> >> >>>> (NOTE: This is not a formal issue against _09 draft). >> >>>> >> >>>> Thanks, >> >>>> >> >>>> /Prasanta >> >>>> >> >>>> -- >> >>>> >> >>>> ------------------------------------------------------------------- >> >>>> -------------- >> >>>> / Ken >> >>>> Laskey \ >> >>>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >> >>>> | 7515 Colshire Drive fax: >> >>>> 703-983-1379 | >> >>>> \ McLean VA >> >>>> 22102-7508 / >> >>>> >> >>>> ------------------------------------------------------------------- >> >>>> --------------- >> >>>> >> >>>> >> >>> -------------------------------------------------------------------- >> >>> ---------------------- >> >>> Ken Laskey >> >>> MITRE Corporation, M/S H305 phone: 703-983-7934 >> >>> 7515 Colshire Drive fax: 703-983-1379 >> >>> McLean VA 22102-7508 >> >>> >> > >> > ---------------------------------------------------------------------- >> > -------------------- >> > Ken Laskey >> > MITRE Corporation, M/S H305 phone: 703-983-7934 >> > 7515 Colshire Drive fax: 703-983-1379 >> > McLean VA 22102-7508 >> > > > >This message contains information that may be privileged or >confidential and is the property of the Capgemini Group. It is >intended only for the person to whom it is addressed. If you are not >the intended recipient, you are not authorized to read, print, >retain, copy, disseminate, distribute, or use this message or any >part thereof. If you receive this message in error, please notify >the sender immediately and delete all copies of this message. >This message contains information that may be privileged or >confidential and is the property of the Capgemini Group. It is >intended only for the person to whom it is addressed. If you are not >the intended recipient, you are not authorized to read, print, >retain, copy, disseminate, distribute, or use this message or any >part thereof. If you receive this message in error, please notify >the sender immediately and delete all copies of this message. -- 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]