OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Title: Re: [soa-rm] Re: Autonomous Services?
<Quote>
Your "true semantics test" lists requirements for the encoding of the 
information not what information needs to be conveyed. 
</Quote>
 
Sorry Ken - I didn't realize that you were asking for the information that needs to be conveyed. Part of this is about framework, and part is about requirements. IOW, absent a robust and appropriate framework (a way of representing the information conveyed), your requirements as to what information needs to be conveyed are moot.
 
As for the framework, as you mentioned the most prevelant effort in this area for Web Services is OWL-S. As for the information to be conveyed, of course much of it would be on a case-by-case basis (e.g. a hotel Web Service would convey its room cancellation policies, while a restaurant would not). Much of it will also be defined by the framework itself - for example, OWL-S' upper ontology that defines properties such as preconditions and results.
 
Q: How much of this is pertinent for our RM?
 
<Quote>
I worry that the term semantics is losing its meaning
</Quote>
 
How ironic ;)
 
Joe
 

Joseph Chiusano

Booz Allen Hamilton

Visit us online@ http://www.boozallen.com



From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Wed 5/4/2005 9:45 AM
To: Chiusano Joseph
Cc: SOA-RM; Frank McCabe
Subject: Re: [soa-rm] Re: Autonomous Services?

Joe,

Your "true semantics test" lists requirements for the encoding of the 
information not what information needs to be conveyed.  Yes, the 
encoding has to be machine readable, but XML takes care of that.  
Correct interpretation implies it must be built on an appropriate (a 
topic for longer discussion) underlying logic; processors built on that 
logic should properly interpret the information but the inference will 
still be limited by the degree to which the supplied information builds 
a sufficiently rich description.  The latter gets to your point (c).

In summary, I agree with where we are trying to go but I worry that the 
term semantics is losing its meaning and we needs to step back and 
consider what capturing semantics and meaning really means.

If you understand what I mean ;-)

Ken

On May 4, 2005, at 7:48 AM, Chiusano Joseph wrote:

>> -----Original Message-----
>> From: Ken Laskey [mailto:klaskey@mitre.org]
>> Sent: Tuesday, May 03, 2005 11:07 PM
>> To: Frank McCabe
>> Cc: 'SOA-RM'
>> Subject: Re: [soa-rm] Re: Autonomous Services?
>>
>> 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.
>
> It's actually much more than that, I believe. The true "semantics 
> test",
> IMO, is: is the information described in a rich-enough manner so that 
> it
> can be:
>
> (a) Processed by machines (which does not yet get to semantic
> technologies, XML handles this aspect);
>
> (b) Interpreted properly according to its truly intended rich meaning
> (this is where the semantic technologies kick in);
>
> (c) Reasoned upon (by cognitive agents and inference engines) to the
> point where inferences can be drawn from the representation that are as
> accurate as a human would infer (we are not completely to this point
> yet);
>
> And there are more I am sure. Data dictionaries stop short of (b) and
> (c).
>
> Joe
>
> Joseph Chiusano
> Booz Allen Hamilton
> Visit us online@ http://www.boozallen.com
>
>> 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
>>
>>
>>
>>
------------------------------------------------------------------------
------------------
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508

*** note change of phone extension from 883 to 983 effective 4/15/2005 
***




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]