RE: [soa-rm] Re: Autonomous Services?

Duane,

Yes, an ontology goes far beyond a data dictionary by supporting the formal
defining of relationships. This provides a more expressive mechanism for
capturing elements of description (where I consider relationships an aspect
of description) but the context for use still defines which relationships
are valuable in establishing common meaning.

There are a number of upper ontology efforts (SUMO is one but there is also
BFO, DOLCE, and inevitably others) but there is a question of how an upper
ontology is best used. There are some who see it as the basis for ontology
mapping but while the connection to an upper ontology would undoubtedly
provide useful information, it is not obvious it would be
sufficient. Another perspective is that 2500 years of philosophy has
debated how things are related and an upper ontology provides a collection
of the results in a way that facilitates a consistent definition of
mid-level down to domain ontologies. But there are still multiple
ontological perspectives to be resolved. Chapter 2 of
http://wonderweb.semanticweb.org/deliverables/documents/D18.pdf does a nice
job of describing some of the choices.

The details of all this goes beyond the SOA RM, making it our challenge to
figure out what level of explanation needs to be in the our final documents.

Ken

At 12:37 PM 5/4/2005, Duane Nickull wrote:
>Ken:
>
>Could I infer from this that an ontology goes further than a mere data
>dictionary in that it not only defines the terms but also captures the
>associations between them. Certain ontologies like SUMO have done a
>wonderful job IMO defining the first order logic and primitives that are
>used to classify associations.
>
>Duane
>
>Ken Laskey wrote:
>
>>I've struggled for a long time on what it means to capture semantics,
>>for example why is an OWL ontology better than a data dictionary. My
>>conclusion (so far) is that conveying semantics (or just pedestrian
>>meaning) is describing enough about a thing (physical or conceptual)
>>that one builds a common picture with someone else. Conveying
>>semantics depends on having some degree of a common framework and
>>then describing the new entity in terms of/as extensions to that
>>framework.   You add more bits of information until the two have a
>>sufficiently common picture for the task at hand. A simpler task may be
>>satisfied by a smaller, simpler set of descriptive elements while
>>something requiring more precision will require more detail. The
>>language used to capture the description has to be sufficiently
>>expressive to capture the information that discriminates entities or
>>shows their commonality.   OWL does a great job on things that can be
>>described in terms of sets while its current form does nothing to
>>express uncertainty. "Storing" semantics is then storing these
>>descriptive elements in a usable, retrievable fashion.
>>
>>Not sure that is a sufficient explanation (i.e. that I have been able
>>to create a sufficiently common picture) but it's all I've got now.
>>
>>Ken
>>
>>On May 2, 2005, at 12:44 PM, Frank McCabe wrote:
>>
>>>+1
>>>In fact, I am hard put to understand how you can *store* semantics.
>>>You can only store data. The best that you can do is store a
>>>description of the semantics; but that is not the same thing.
>>>
>>>On that theme, IBM and others at the U of Georgia recently released
>>>a paper on semantic annotations of Web services. Have not yet had
>>>the time to digest this properly, but could be interesting... if IBM
>>>makes a play in the standards space with this.
>>>
>>>The link to the paper is:
>>>
>>>http://www.alphaworks.ibm.com/g/g.nsf/img/semanticsdocs/$file/
>>>wssemantic_annotation.pdf
>>>
>>>Frank
>>>
>>>
>>>On May 2, 2005, at 9:30 AM, Duane Nickull wrote:
>>>
>>>>John
>>>>(aka "Meggan". Hey - how you dress in private is none of our
>>>>business ;-)
>>>>
>>>>Just joking!!
>>>>
>>>>This is a good question.
>>>>
>>>>The registry is one way that one could store semantics however
>>>>semantics are not required to be explicit and there are other
>>>>models for sharing information beside registry. At the abstract level
>>>>it represents a facet of the model where the information available
>>>>is meaningful. Therefore, a registry will not be in the reference
>>>>model as a normative, core element.
>>>>
>>>>We decided to add a non normative section to explain some of these
>>>>manifestations. How one goes from "Data Model" to Messages,
>>>>Availability to Registry, Policy to on the wire security etc.
>>>>
>>>>It would be great if you could hook up with the person with this
>>>>section and offer proof reading services. Value your input.
>>>>
>>>>Duane
>>>>
>>>>
>>>>
>>>>
>>>>meggan hardin wrote:
>>>>
>>>>
>>>>>My assumptions (so far) about the central metadata concepts have
>>>>>been that the reg/rep holds this data. Are we delving to the level
>>>>>of defining specific types of resources / components that should
>>>>>be included in a major component such as the reg/rep? I think that
>>>>>the concept of storing semantic metadata as an independent
>>>>>integration reference point is important enough to be included in the RM.
>>>>>
>>>>>FWIW - Contivo terms the semantic metadata repository the
>>>>>"enterprise vocabulary"...
>>>>>
>>>>>john
>>>>>
>>>>>Smith, Martin wrote:
>>>>>
>>>>>
>>>>>>Violent agreement.
>>>>>> martin
>>>>>>________________________________
>>>>>>
>>>>>>From: Schuldt, Ron L [mailto:ron.l.schuldt@lmco.com]
>>>>>>Sent: Fri 4/29/2005 6:39 PM
>>>>>>To: Smith, Martin; Sharma, Sameer; Duane Nickull;
>>>>>>john@crossconnections.ws
>>>>>>Cc: ebSOA OASIS TC; soa-rm@lists.oasis-open.org
>>>>>>Subject: RE: [soa-rm] Re: Autonomous Services?
>>>>>>
>>>>>>
>>>>>>
>>>>>>Sameer will correct me if I'm wrong, but I believe that his intent was
>>>>>>to include the notion of central metadata within a "Reference
>>>>>>Architecture" not the Reference Model. Appendix B is the place where
>>>>>>example use cases would be defined. I suspect that Sameer might be
>>>>>>willing to submit an example use case.
>>>>>>
>>>>>>Ron Schuldt
>>>>>>Senior Staff Systems Architect
>>>>>>Lockheed Martin Enterprise Information Systems
>>>>>>11757 W. Ken Caryl Ave.
>>>>>>#F521 Mail Point DC5694
>>>>>>Littleton, CO 80127
>>>>>>303-977-1414
>>>>>>ron.l.schuldt@lmco.com
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>>>>>>Sent: Friday, April 29, 2005 4:19 PM
>>>>>>To: Sharma, Sameer; Duane Nickull; john@crossconnections.ws
>>>>>>Cc: ebSOA OASIS TC; soa-rm@lists.oasis-open.org
>>>>>>Subject: RE: [soa-rm] Re: Autonomous Services?
>>>>>>
>>>>>>
>>>>>>Sameer - -
>>>>>>
>>>>>>Let me practice being Matt <g>:
>>>>>>
>>>>>>The term " 'central' metadata" presumes a specific implementation
>>>>>>strategy and should not be in the RM. Perhaps "metadata associated with
>>>>>>the service should be available in the environment." Now in my
>>>>>>example
>>>>>>SOA for Appendix B, I'll probably show a UDDI services directory, or
>>>>>>maybe a combo registry/repository that can in fact store all the
>>>>>>description metadata.
>>>>>>
>>>>>>Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Sharma, Sameer [mailto:sameer.sharma@lmco.com]
>>>>>>Sent: Friday, April 29, 2005 2:16 PM
>>>>>>To: Smith, Martin; Duane Nickull; john@crossconnections.ws
>>>>>>Cc: ebSOA OASIS TC; soa-rm@lists.oasis-open.org
>>>>>>Subject: RE: [soa-rm] Re: Autonomous Services?
>>>>>>
>>>>>>
>>>>>>My feeling is that some of what you are alluding to might be
>>>>>>covered by
>>>>>>UDDI,
>>>>>>however as is happening in an instance of SOA deployment that I am
>>>>>>involved
>>>>>>in - UDDI by itself is not going to be sufficient to express all the
>>>>>>metadata
>>>>>>that is needed for a client to successfully and contextually
>>>>>>interpret
>>>>>>all
>>>>>>that a Web Service does.
>>>>>>
>>>>>>My attempted solution is to capture this additional metadata by
>>>>>>leveraging
>>>>>>central metadata services of my enterprise. I guess what I am
>>>>>>saying is
>>>>>>that
>>>>>>the concept of "central metadata" might be a valid candidate as a
>>>>>>component of
>>>>>>the Reference Architecture we are considering.
>>>>>>
>>>>>>Since I was unable to participate in the F2F, (due to some last
>>>>>>minute
>>>>>>commitments that I got called into), if this topic was discussed,
>>>>>>please
>>>>>>accept my apologies for bringing it up again.
>>>>>>
>>>>>>Thanks!
>>>>>>
>>>>>>
>>>>>>
>>>>>>L
>>>>>>   Sameer Sharma
>>>>>>     Principal Applications Architect
>>>>>>     Lockheed Martin Corporation
>>>>>>     Chief Technology Office (CTO)
>>>>>>     12506 Lake Underhill Road - MP 166
>>>>>>     Orlando, FL-32825
>>>>>>     Tel: (407) 306 5640
>>>>>>     Fax:(407) 306 1392
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Smith, Martin [mailto:Martin.Smith@DHS.GOV]
>>>>>>Sent: Friday, April 29, 2005 1:38 PM
>>>>>>To: Duane Nickull; john@crossconnections.ws
>>>>>>Cc: ebSOA OASIS TC; soa-rm@lists.oasis-open.org
>>>>>>Subject: RE: [soa-rm] Re: Autonomous Services?
>>>>>>
>>>>>>Folks - -
>>>>>>
>>>>>>On my way home from N'awlins Wed night, I had a thought on this
>>>>>>discussion.
>>>>>>
>>>>>>I think we expect services in an SOA to be independent of the kind of
>>>>>>shared contextual knowledge we usually presume within a local
>>>>>>computing
>>>>>>environment. We expect that the requesting service will be able to
>>>>>>obtain all the info it needs to use the responding service
>>>>>>successfully
>>>>>>by processing the responding service's description metadata. I do think
>>>>>>this is a core characteristic of SOA services.
>>>>>>
>>>>>>I'm not suggesting we reinstate the use of the word "autonomous" as a
>>>>>>handle for this concept since it demonstrably caused confusion at
>>>>>>the
>>>>>>f2f. If we need a handle, perhaps "self-sufficient" or
>>>>>>"self-documenting" or "introspective" (naaah - forget that one.)
>>>>>>
>>>>>>Martin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Duane Nickull [mailto:dnickull@adobe.com]
>>>>>>Sent: Friday, April 29, 2005 12:43 PM
>>>>>>To: john@crossconnections.ws
>>>>>>Cc: ebSOA OASIS TC; soa-rm@lists.oasis-open.org
>>>>>>Subject: [soa-rm] Re: Autonomous Services?
>>>>>>
>>>>>>We discussed and the submitter withdrew the submission pending
>>>>>>clarification on exactly what is meant by Autonomous nature WRT
>>>>>>services. It may be re-submitted and probably will however we do
>>>>>>not
>>>>>>have consensus on it at present.
>>>>>>
>>>>>>Duane
>>>>>>
>>>>>>john c hardin wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Duane and SOA-RM group -
>>>>>>>Can someone enlighten the members of the eb-soa group regarding a
>>>>>>>description of Autonomous Services? Any resulting conversations
>>>>>>>from
>>>>>>>the meetings this week, on the subject of Autonomous Services
>>>>>>>would be
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>good also.
>>>>>>>
>>>>>>>thanks
>>>>>>>john
>>>>>>>
>>>>>>
>>>>>>
>>>>>>--
>>>>>>***********
>>>>>>Senior Standards Strategist - Adobe Systems, Inc. -
>>>>>>http://www.adobe.com
>>>>>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>>>>>>Adobe Enterprise Developer Resources -
>>>>>>http://www.adobe.com/enterprise/developer/main.html
>>>>>>***********
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>--
>>>>***********
>>>>Senior Standards Strategist - Adobe Systems, Inc. -
>>>>http://www.adobe.com
>>>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>>>>Adobe Enterprise Developer Resources -
>>>>http://www.adobe.com/enterprise/developer/main.html
>>>>***********
>>>>
>>>
>>------------------------------------------------------------------------
>>------------------
>>Ken Laskey
>>MITRE Corporation, M/S H305     phone: 703-983-7934
>>7515 Colshire Drive                        fax:        703-983-1379
>>McLean VA 22102-7508
>>
>
>--
>***********
>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
>Chair - OASIS Service Oriented Architecture Reference Model Technical
>Committee - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>Adobe Enterprise Developer Resources -
>http://www.adobe.com/enterprise/developer/main.html
>***********
>

--
      ---------------------------------------------------------------------------------
   /   Ken
Laskey                                                                \
|    MITRE Corporation, M/S H305    phone: 703-983-7934   |
|    7515 Colshire Drive                    fax:      703-983-1379   |
   \   McLean VA 22102-7508                                              /
     ----------------------------------------------------------------------------------

*** note: phone number changed 4/15/2005 to 703-983-7934 ***

soa-rm message