[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]