I've used the following analogy when describing Topic Maps in relation to RDF
and other "knowledge-management" technologies. --- Consider an organization to
be like a "book", full of information, but not well organized, not highly
navigable, and not searchable. Topic Maps provide the functional equivalent of
a hyperlinked "index" (including concordance capabilities) to this
'organization as a book", while technologies like RDF provided the functional
equivalent to a "Table of Contents" to the book. (01)
RDF focuses on hierarchy and categorization/classification/taxonomy, while
Topic Map focuses on associations/relations/networks/lattices. I believe that
OWL provides both the "Table of Contents" and the "Index" to the subject being
modeled. (02)
Notice that in the General Ontology approach I've suggested to this ONTAC
forum, the seven GO "Reference Catalogs" provide the table of contents to the
enterprise's architecture (as a knowledge-base), while the "Relation Types"
provide an organizing structure for the relations/associations. (03)
Roy
CommIT Enterprises, Inc.
Enterprise Architecture for Enterprise Management, Security, and Knowledge (04)
Roy Roebuck III
Senior Enterprise Architect
2231 Crystal Drive, Ste 501
Arlingon, VA 22202
roy.roebuck@xxxxxxxxxxxxx
mobile:
fax:
direct:
+1 (703)-598-2351
+1 (703) 486-5540
+1 (703) 486-5506
Add me to your address book...
(05)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rex Brooks
Sent: Tuesday, December 13, 2005 12:32 PM
To: [ontolog-forum] ; soa-rm@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [soa-rm] RE: [ontolog-forum] RE: [soa-rm] latest Draft of Concept
Map / N-ary Documents specification? (06)
Interesting, Folks, (07)
I would actually prefer if concept maps stayed informal or relatively
informal for usefulness in my brainstorming process before moving on
to my personal process for noodling out constraints. I've also
actually used Topic Maps, though more for lack of rich semantics,
which OWL Lite and DL now provide for my purposes. However, I never
delved very deeply into Topic Maps due mostly to the inherent
restrictions of association-only context. (08)
However, that doesn't mean that I don't think Topic Maps are useful,
just that one needs to choose one's preferred tool on the basis of
which one performs the task one needs done best. Of course, that
depends on your criteria for what is best, and for me, that is the
tool that gets the results I'm looking for in the most simple and
straightforward way. Then I sometimes look at the computational
overhead, if I am looking to employ the tool under the covers at
runtime. (09)
Since my long range goal is to employ knowledge representations
within user-configurable business or organizational rules to make
inferences about applicable datasets for decision-support in
emergency management and healthcare fields, there appear to needs to
employ Topic Maps to assemble a resource set or sets and then
ontologies and ontological tools to provide logical choices within
the resource sets. (010)
BTW Peter, I don't think RDF was ever intended to make distinctions
on its own, but, rather, to allow distinctions to be made, and it is
ever caveat emptor with regard any given representation of any given
distinction. To carry it further, I would prefer having a next
generation RDF tool to make n-ary tuples, as opposed to triples for
richer semantics. However, I suspect we better get first-order logic
working before we move on to that. (011)
Cheers,
Rex (012)
At 3:22 PM +0100 12/13/05, Smith, Barry wrote:
>Does Topic Maps have a way to define logically the relation between
>
> A adjacent_to B
>
>on the level of concepts and
>
> a adjacent_to b
>
>on the level of instances, in terms of the
>
> a instance_of A
>
>relation?
>BS
>
>At 02:57 PM 12/13/2005, peter@xxxxxxxxxxxxx wrote:
>>I think Topic Maps does, yes. Both because you are able to define
>>whatever association types you need (and none are pre-defined, so
>>you have complete control there) and constrain their use; and the
>>fact that the conceptual model of the standard makes the
>>distinction between occurrences and topics as different classes of
>>"thing", conceptual and real-world, something RDF singularly fails
>>to do
>>
>>Peter
>>
>>-----Original Message-----
>>From: Smith, Barry [mailto:phismith@xxxxxxxxxxx]
>><snip/>
>>Are Topic Maps able to do justice to the fact that associations
>>defined between concepts typically behave differently from
>>associations defined between real-world instances?
>>
>>Thus on the instance level the relation of adjacency between
>>cytoplasm and cell nucleus is always symmetric. (Adjacency must be
>>symmetric, right?)
>>
>>But on the concept level, while we have
>>
>>cell nucleus adjacent_to cytoplasm
>>
>>we do not have
>>
>>cytoplasm adjacent_to cell nucleus
>>
>>because not every cell has a nucleus.
>>BS
>>
>>
>>>Peter
>>>
>>>-----Original Message-----
>>>From: Chiusano Joseph [mailto:chiusano_joseph@xxxxxxx]
>>>Sent: 12 December 2005 22:49
>>>To: peter@xxxxxxxxxxxxx; [ontolog-forum] ; Duane Nickull;
>>>soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>Subject: [soa-rm] RE: [ontolog-forum] RE: [soa-rm] latest Draft of
>>>Concept Map / N-ary Documents specification?
>>>
>>>I see concept maps and topic maps as 2 distinct things, each
>>>having value in different situations - with the understanding that
>>>there may be situations in which both have value.
>>>
>>>Joe
>>>
>>>Joseph Chiusano
>>>Associate
>>>Booz Allen Hamilton
>>>
>>>700 13th St. NW, Suite 1100
>>>Washington, DC 20005
>>>O: 202-508-6514
>>>C: 202-251-0731
>>>Visit us online@ http://www.boozallen.com
>>>
>>>
>>>> -----Original Message-----
>>>> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
>>> > [mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of
>>>Peter F > Brown
>>>> Sent: Monday, December 12, 2005 4:46 PM
>>>> To: 'Duane Nickull'; '[ontolog-forum] '; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> Subject: [ontolog-forum] RE: [soa-rm] latest Draft of Concept
>>>>Map / > N-ary Documents specification?
>>>>
>>>> All:
>>>> I might be somewhat late on this thread, but trying to play
>>>>catch up > between the daytime F2F this week and my day-job work
>>>>in the > evening...
>>>>
>>>> I'm wondering if the proposal is not actually redundant:
>>>> there is a standard out there for handling N-ary relationships
>>>>in > the way you want (or at least in the way I've understood
>>>>it): ISO > 13250:2000 Topic Maps. What's more the relationships
>>>>(or
>>>> "associations") are typed, giving a further level of control
>>>>that > something like RDF doesn't offer.
>>>>
>>>> You can find a useful summary of this particular aspect of TM
>>>>at > http://www.w3.org/2002/06/09-RDF-topic-maps/
>>>>
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: Duane Nickull [mailto:dnickull@xxxxxxxxx]
>>>> Sent: 08 December 2005 19:10
>>>> To: Frank McCabe; [ontolog-forum]
>>>> Cc: Metz Rebekah; Bashioum, Christopher D; > soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> Subject: [soa-rm] latest Draft of Concept Map / N-ary
>>>>Documents > specification?
>>>>
>>>> All:
>>>>
>>>> Here it is. I stopped when I started asking some rather
>>>>detailed > questions that may best be left vague. The fear is
>>>>that the concept > map notation may become just as complex as UML
>>>>CVD's. Interpret the > logic using KIF.
>>>>
>>>> Several people from the Ontolog Forum have looked at it and
>>>>also > expressed interest in continuing the work.
>>>>
>>>> Do you guys think this might be the basis for a TC? If not -
>>>>where > might this find a nice home to be completed?
>>>>
>>>> Duane
>>>>
>>>> *******************************
>>>> Adobe Systems, Inc. - http://www.adobe.com Vice Chair -
>>>>UN/CEFACT > http://www.uncefact.org/ Chair - OASIS SOA Reference
>>>>Model Technical > Committee Personal Blog -
>>>>http://technoracle.blogspot.com/
>>>> *******************************
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Frank McCabe [mailto:frank.mccabe@xxxxxxxxxxxxxx]
>>>> Sent: Thursday, December 08, 2005 9:53 AM
>>>> To: Duane Nickull
>>>> Cc: Metz Rebekah; Bashioum, Christopher D; > soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft
>>>>for > Better
>>>>
>>>> Duane:
>>>> Did you send something out before?
>>>> In any case, I would be quite interested in taking a look.
>>>>
>>>> I wonder if there but be enough groundswell for an actual
>>>>concept > map TC?
>>>> As a modeling tool.
>>>>
>>>> Frank
>>>>
>>>> On Dec 8, 2005, at 9:44 AM, Duane Nickull wrote:
>>>>
>>>> > I have an initial submission for this TC if anyone is
>>>> interested. I
>>>> > have kind of stopped working on it due to time constraints
>>>> but would
>>>> > welcome anyone else who wants to work on it. I have not
>>>>yet > > contributed it to the TC but will if there is consensus.
>>>> >
>>>> > D
>>>> >
>>>> > *******************************
>>>> > Adobe Systems, Inc. - http://www.adobe.com Vice Chair -
>>>>UN/CEFACT > > http://www.uncefact.org/ Chair - OASIS SOA
>>>>Reference Model
>>>> Technical
>>>> > Committee Personal Blog - http://technoracle.blogspot.com/
>>>> > *******************************
>>>> >
>>>> >
>>>> > -----Original Message-----
>>>> > From: Francis McCabe [mailto:fgm@xxxxxxxxxxxxxxx]
>>>> > Sent: Thursday, December 08, 2005 9:28 AM
>>>> > To: Duane Nickull
>>>> > Cc: Metz Rebekah; Bashioum, Christopher D;
>>>> soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> > Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft
>>>>for > > Better
>>>> >
>>>> > Perhaps we need an OASIS spec on concept maps ....
>>>> >
>>>> > On Dec 7, 2005, at 10:40 PM, Duane Nickull wrote:
>>>> >
>>>> >> I believe that the problem, with is largely due to the
>>>> fact there is
>>>> >> no normative reference for how to interpret concept maps.
>>>>In > >> this case, a service is neither an action nor an object.
>>>>It is
>>>> imply an
>>>> >> abstract concept.
>>>> >>
>>>> >>
>>>> >>
>>>> >> D
>>>> >>
>>>> >>
>>>> >>
>>>> >> *******************************
>>>> >> Adobe Systems, Inc. - http://www.adobe.com Vice Chair -
>>>>UN/CEFACT > >> http://www.uncefact.org/ Chair - OASIS SOA
>>>>Reference Model
>>>> Technical
>>>> >> Committee Personal Blog - http://technoracle.blogspot.com/
>>> > >> *******************************
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Metz Rebekah [mailto:metz_rebekah@xxxxxxx]
>>>> >> Sent: Wednesday, December 07, 2005 7:18 PM
>>>> >> To: Bashioum, Christopher D; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Bashioum, Christopher D [mailto:cbashioum@xxxxxxxxx]
>>>> >> Sent: Wednesday, December 07, 2005 5:06 PM
>>>> >> To: Metz Rebekah; soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> Rebekah,
>>>> >>
>>>> >>
>>>> >>
>>>> >> what about the potential of an act?
>>>> >>
>>>> >>
>>>> >>
>>>> >> [->] The potential of service is an offer.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I have a problem with the following
>>>> >>
>>>> >>
>>>> >>
>>>> >> <Snip>
>>>> >>
>>>> >> The actual invocation and performance of the capability is
>>>>the > >> service; i.e. the action.
>>>> >>
>>>> >> </Snip>
>>>> >>
>>>> >>
>>>> >>
>>>> >> if I understand what you are saying here, it would imply that
>>>>a > >> service is not a service until it is actually performing
>>>>an action.
>>>> >> During the time that it is "waiting" to perform an action
>>>> it is not a
>>>> >> service, nor is it after it has completed the action it
>>>> was created
>>>> >> to do.
>>>> >>
>>>> >>
>>>> >>
>>>> >> [->] yes, you are right. That is exactly what I'm implying.
>>>>The > >> service isn't performing the action, the implementation
>>>>of
>>>> the action
>>>> >> is. The service is the performance.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> In Duane's diagram, the service exists independent of
>>>>the > >> interaction. However, the interaction is what causes the
>>>> real- world
>>>> >> effect.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I'm not sure I buy the other statement that a service is an
>>>>act > >> as opposed to an object. Isn't it an object (in that it
>>>> exists) who's
>>>> >> purpose is to perform an act?
>>>> >>
>>>> >> [->] So I'll ask a question in return. Let's assume the
>>>> statement is
>>>> >> true. If a service exists as an object that is independent
>>>>of > >> the capability who's purpose it is to perform; what > >>
>>>>differentiates the service from the capability?
>>>> >>
>>>> >>
>>>> >>
>>>> >> For that matter, is the capability what is actually
>>>> providing the
>>>> >> "action" and the service is the means to access that action?
>>>> >>
>>>> >> [->] From this perspective, what differentiates the
>>>> service from the
>>>> >> service access point?
>>>> >>
>>>> >>
>>>> >>
>>>> >> [->] My point is that the conceptualization of service as
>>>> an object
>>>> >> doesn't provide resolution to these questions. It is for
>>>> this reason
>>>> >> that I started examining service as a verb rather than a
>>>> noun. From
>>>> >> that perspective, the concepts and the relationships between
>>>>them > >> clarified.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Rebekah
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Metz Rebekah [mailto:metz_rebekah@xxxxxxx]
>>>> >> Sent: Wednesday, December 07, 2005 4:37 PM
>>>> >> To: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >> Gosh - if this email came through in some weird format for
>>>> everyone
>>>> >> else, I am terribly sorry about the wacky formatting of
>>>>this > >> email thread. Not sure if everyone saw it as I did,
>>>>but at least > >> my outlook client puked =)
>>>> >>
>>>> >>
>>>> >>
>>>> >> Uh-oh. We seem to be starting to head back to the service as
>>>>an > >> object as opposed to an act. I still do not believe that
>>>>a service
>>>> >> is an 'object.' In fact, I believe that assumption has caused
>>>> >> much of the difficulty in figuring out what a service actually is.
>>>> >>
>>>> >>
>>>> >>
>>>> >> What is invoked is a capability, consistent with the
>>>>execution > >> context and so to produce real world effects. The
>>>>actual
>>>> invocation
>>>> >> and performance of the capability is the service; i.e.
>>>> >> the action. Hence I maintain that visibility, interaction
>>>> and effect
>>>> >> are the interrelated concepts often (yet confusingly)
>>>>referred to > >> with a shorthand nomenclature of 'service.'
>>>> >>
>>>> >>
>>>> >>
>>>> >> As far as roles go, the very essence of the word service is
>>>>the > >> recognition that <someone> does <something> for <someone
>>>>else>.
>>>> >> I would agree that any other specification of this
>>>>generalization > >> (uh...
>>> > >
>>>> >> isn't that an ontology) belongs in something other than the RM.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Rebekah
>>>> >>
>>>> >>
>>>> >>
>>>> >> Rebekah Metz
>>>> >>
>>>> >> Associate
>>>> >>
>>>> >> Booz Allen Hamilton
>>>> >>
>>>> >> Voice: (703) 377-1471
>>>> >>
>>>> >> Fax: (703) 902-3457
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Ken Laskey [mailto:klaskey@xxxxxxxxx]
>>>> >> Sent: Wednesday, December 07, 2005 4:19 PM
>>>> >> To: Metz Rebekah
>>>> >> Cc: Jones, Steve G; marchadr@xxxxxxxxxxxxxx;
>>>>tmathews@xxxxxxx; > >> mattm@xxxxxxxxx;
>>>>soa-rm@xxxxxxxxxxxxxxxxxxxx; > >> frank.mccabe@xxxxxxxxxxxxxx;
>>>>goran.zugic@xxxxxxxxxxxxx; > >> McGregor.Wesley@xxxxxxxxxxxxx;
>>>>dnickull@xxxxxxxxx; > >> sallystamand@xxxxxxxxx
>>>> >> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> inline
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Dec 7, 2005, at 4:00 PM, Metz Rebekah wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> Comments inline...
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Ken Laskey [mailto:klaskey@xxxxxxxxx]
>>>> >>
>>>> >> Sent: Wednesday, December 07, 2005 3:43 PM
>>>> >>
>>>> >> To: Jones, Steve G
>>>> >>
>>>> >> Cc: marchadr@xxxxxxxxxxxxxx; tmathews@xxxxxxx;
>>>> mattm@xxxxxxxxx; soa-
>>>> >> rm@xxxxxxxxxxxxxxxxxxxx; frank.mccabe@xxxxxxxxxxxxxx; > >>
>>>>goran.zugic@xxxxxxxxxxxxx; McGregor.Wesley@xxxxxxxxxxxxx; > >>
>>>>dnickull@xxxxxxxxx; sallystamand@xxxxxxxxx
>>>> >>
>>>> >> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> If I invoke a service, I am a service consumer. It does
>>>> not matter if
>>>> >> I invoke the service on my own initiative or am told to do
>>>>it > >> (through a targeted instruction or as part of a more
>>>> complex set of
>>>> >> instructions), I am still the service consumer.
>>>> >>
>>>> >>
>>>> >>
>>>> >> [->] Agreed.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I could glibly say that if I "provide" a service, I'm a
>>>>service > >> provider, but I fear things are not that simple. Is
>>>>the
>>>> entity that
>>>> >> created the service its provider, or the one who maintains
>>>> it, or the
>>>> >> one who hosts it, or the one who pays for it, or ...?
>>>> >>
>>>> >> [->] I see this being a question of 'what are the roles' versus
>>>> >> 'who plays the roles'. At first pass, it seems right that we
>>>> >> recognize the roles @ the RM level and leave the details
>>>>of > >> determining the best way to decide how to assign some
>>>>entity into > >> that role to the RA.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I think it is easy to start naming roles but difficult to
>>>> stop, and
>>>> >> the roles will get more use-specific.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Luckily, from the RM standpoint, we don't care.
>>>> >>
>>>> >> [->] or do we just delegate =)
>>>> >>
>>>> >>
>>>> >>
>>>> >> ... to someone who has no choice but to care ;-)
>>>> >>
>>>> >> To be used within the context of SOA, the service must
>>>>be > >> visible, must be able to take part in an interaction
>>>> >>
>>>> >> [->] Here it sounds like the service is an active player in
>>>>an > >> interaction. Isn't it that the service consumer and
>>>>provider > >> interact (as specified...?
>>>> >>
>>>> >>
>>>> >>
>>>> >> Isn't the service an active player? I invoke it to get its
>>>> real world
>>>> >> effect, so it certainly sounds like it does something.
>>>> >>
>>>> >>
>>>> >>
>>>> >> (as specified by the established execution context), and
>>>> must produce
>>>> >> a real world effect (which I assume may in some circumstances
>>>>be > >> null). It has been "provided" but we don't care how or by
>>>>whom.
>>>> >>
>>>> >>
>>>> >>
>>>> >> So, in summary, there's a lot of muddy water but sometimes we
>>>>can > >> avoid playing in it. :-)
>>>> >>
>>>> >> [->] Or we can draw a circle around it and leave that to the RA > >> =)
>>>> >>
>>>> >>
>>>> >>
>>>> >> ... at which point you initially choose RA cases that you
>>>>can > >> more cleanly defined. You eventually get to the tougher
>>>>ones, but > >> we should learn to ride a bicycle before we get a
>>>>motorcycle > >> (unless Duane has a different perspective)
>>>> >>
>>>> >>
>>>> >>
>>>> >> Ken
>>>> >>
>>>> >> [->] Rebekah
>>>> >>
>>>> >>
>>>> >>
>>>> >> Ken
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> If I make a service available for someone to invoke (and
>>>> here I would
>>>> >> say that "make available"
>>>> >>
>>>> >> On Dec 7, 2005, at 4:47 AM, Jones, Steve G wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> To add some mud into the water...
>>>> >>
>>>> >>
>>>> >>
>>>> >> Many Bus architectures do "enrichment" of messages between
>>> > consumer
>>>> >> and producer, including the invocation of other services
>>>> to perform
>>>> >> that enrichment (e.g stock quote returns current price, > >>
>>>>enrichment provides the last ten days closing price). They
>>>>may > >> also do calculations that result in the non-connection
>>>>or "empty"
>>>> return from
>>>> >> the service (e.g. if you call for "last five minutes trades"
>>>> >> after the market has closed... its an empty set). So
>>>> while I agree
>>>> >> that the service consumer is key it's sometimes hard to
>>>> identify the
>>>> >> true consumer and the true producer of a service within a
>>>> virtualised
>>>> >> bus.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Steve
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: McGregor.Wesley@xxxxxxxxxxxxx
>>>[<mailto:McGregor.Wesley@tbs->mailto:McGregor.Wesley@tbs-
>>>> >> sct.gc.ca]
>>>> >>
>>>> >> Sent: 06 December 2005 19:09
>>>> >>
>>>> >> To: klaskey@xxxxxxxxx; marchadr@xxxxxxxxxxxxxx;
>>>> dnickull@xxxxxxxxx;
>>>> >> goran.zugic@xxxxxxxxxxxxx; mattm@xxxxxxxxx;
>>>>tmathews@xxxxxxx; > >> sallystamand@xxxxxxxxx;
>>>>frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> I agree with Ken.
>>>> >>
>>>> >>
>>>> >>
>>>> >> The service consumer is the key concept that indicates the
>>>>entity > >> that invoked the service in the first place.
>>>> >>
>>>> >>
>>>> >>
>>>> >> A brokering service or service actor is merely a middle-man.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Wes
>>>> >>
>>>> >> -----Original Message-----
>>>> >>
>>>> >> From: Ken Laskey [mailto:klaskey@xxxxxxxxx]
>>>> >>
>>>> >> Sent: December 6, 2005 2:02 PM
>>>> >>
>>>> >> To: marchadr@xxxxxxxxxxxxxx; dnickull@xxxxxxxxx; > >>
>>>>goran.zugic@xxxxxxxxxxxxx; mattm@xxxxxxxxx;
>>>>tmathews@xxxxxxx; > >> sallystamand@xxxxxxxxx;
>>>>frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> I could argue that a broker consumes the service on
>>>>someone > >> else's behalf. In reality, service actor seems too
>>>> nondescriptive because
>>>> >> either the consumer or the provider can be thought of as an actor.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Ken
>>>> >>
>>>> >>
>>>> >>
>>>> >> At 01:45 PM 12/6/2005, marchadr@xxxxxxxxxxxxxx wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> I hate to stir things up a bit, but can you change the
>>>>service > >> consumer term to service actor?
>>>> >>
>>>> >> Since in the case of brokering the service actor is not
>>>> consuming but
>>>> >> brokering a request to another service.
>>>> >>
>>>> >> The broker service can be a service actor upon the service
>>>> but might
>>>> >> not really consume any part of the service since it is a
>>>>pass > >> through.
>>>> >>
>>>> >>
>>>> >>
>>>> >> But I guess this is a matter of opinion.
>>>> >>
>>>> >>
>>>> >>
>>>> >> - Dan
>>>> >>
>>>> >> -----Original Message-----
>>>> >>
>>>> >> From: Ken Laskey [ mailto:klaskey@xxxxxxxxx]
>>>> >>
>>>> >> Sent: Tuesday, December 06, 2005 10:39 AM
>>>> >>
>>>> >> To: Duane Nickull; Goran Zugic; Matt MacKenzie; MATHEWS,
>>>> Tim; Sally
>>>> >> St. Amand; frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >>
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> I think we need to add some words to the RM to capture
>>>>this > >> discussion. We cover part of this in the beginning of
>>>>Section
>>>> >> 3.2.1 but need to be more specific that:
>>>> >>
>>>> >>
>>>> >>
>>>> >> - a service consumer can be a human or a software agent;
>>>> >>
>>>> >>
>>>> >>
>>>> >> - a service consumer can invoke any number of services
>>>> (including a
>>>> >> single service in isolation) and can chain the output of
>>>>some > >> services to act as the input of others;
>>>> >>
>>>> >>
>>>> >>
>>>> >> - from the perspective of a given service, the occurrence of
>>>>such > >> chaining would not be visible;
>>>> >>
>>>> >>
>>>> >>
>>>> >> - the service consumer can be implementing a business process;
>>>> >>
>>>> >>
>>>> >>
>>>> >> - the specific of a business process do not change the basic
>>>>SOA > >> concepts as described in the RM; however, the specific
>>>> architecture
>>>> >> that one designs and implements will reflect the business
>>>> process and
>>>> >> make use of specific service instances that corresponds to
>>>> the real
>>> > >> world effects that the business process hopes to realize.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Now that said, and in full appreciation that we agreed
>>>> earlier that
>>>> >> mechanisms which combine services (e.g. choreography,
>>>> >> orchestration) are out of scope, is it sufficient for
>>>> words, such as
>>>> >> those suggested above, to be included somewhere within
>>>>the > >> current discussion or do we need to pull it out into a
>>>>subsection
>>>> on its own?
>>>> >> As an example of the former, we tried to deal with
>>>> loose-coupling and
>>>> >> coarse-grained with words at the end of Section 2.1.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Ken
>>>> >>
>>>> >> At 12:23 PM 12/6/2005, Duane Nickull wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> Goran:
>>>> >>
>>>> >>
>>>> >>
>>>> >> I slightly disagree with your assertions, probably based
>>>>on > >> semantics. For a service to "participate" in a process,
>>>>it would > >> have to be aware of the process (which many will
>>>>not be).
>>>> A better
>>>> >> way to depict this may be to state "services may be
>>>>aggregated > >> and used by processes" and "processes may be
>>>>represented/exposed > >> as services". There are really no
>>>>limits to the number of
>>>> layers that
>>>> >> can be present. Attached is a UML CVD depicting such.
>>>> >>
>>>> >>
>>>> >>
>>>> >> A key rationale of why process is not part of SOA is
>>>>that > >> services cannot see process. They are not aware of
>>>>whether they > >> are being called as part of a process vs. as an
>>>>individual service.
>>>> If the "s"
>>>> >> part of SOA cannot see or touch that, it cannot be part of the RM.
>>>> >>
>>>> >>
>>>> >>
>>>> >> The chicken and egg discussion you bring forward is a
>>>> requirement for
>>>> >> those building services to strongly consider the business
>>>>process > >> when designing their service infrastructure.
>>>>Accordingly,
>>>> it is not
>>>> >> really part of the RM for SOA yet I agree that it is a
>>>> very important
>>>> >> consideration.
>>>> >>
>>>> >>
>>>> >>
>>>> >> For your messages to get to the list, you must join as a
>>>> "applicant"
>>>> >> rather than an "observer" as per OASIS process.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Duane
>>>> >>
>>>> >>
>>>> >>
>>>> >> *******************************
>>>> >>
>>>> >> Adobe Systems, Inc. - http://www.adobe.com
>>>> >>
>>>> >> Vice Chair - UN/CEFACT http://www.uncefact.org/
>>>> >>
>>>> >> Chair - OASIS SOA Reference Model Technical Committee
>>>> >>
>>>> >> Personal Blog - http://technoracle.blogspot.com/
>>>> >>
>>>> >> *******************************
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Goran Zugic [ mailto:goran.zugic@xxxxxxxxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 8:47 PM
>>>> >>
>>>> >> To: Duane Nickull; Matt MacKenzie; MATHEWS, Tim; Sally St.
>>>>Amand; > >> frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> Duane,
>>>> >>
>>>> >>
>>>> >>
>>>> >> Thanks for the response. Yes I would like to see the PPT.
>>>> I hope you
>>>> >> do not mind if I add few more thoughts related to services
>>>>and > >> business processes:
>>>> >>
>>>> >>
>>>> >>
>>>> >> Services participate in a business process to add some value to it.
>>>> >> They can be governed and evaluated using business process metrics.
>>>> >> One service can participate in many business processes
>>>>and > >> provide value to each of them according to the context
>>>>within that process.
>>>> >> As far as SOA is concerned it is as important to know what
>>>>the > >> service does, how it can be discovered, contacted,
>>>> invoked, executed,
>>>> >> etc. as it is to be able to use it within the process
>>>>context, > >> measure it and assess its value from the business
>>>>process > >> requirements point of view. SOA needs to avoid
>>>>typical new
>>>> technology
>>>> >> chicken and egg syndrome, e.g. companies not producing
>>>>services > >> because there are no service friendly process
>>>>definitions
>>>> to use them
>>>> >> and not having SOA friendly process definitions because
>>>> there are no
>>>> >> services to use. Services do not have to know if they will
>>>>be > >> involved in the process upfront, they will be contacted
>>>>on demand > >> according to the process script that is in effect,
>>>>and
>>>> they will be
>>>> >> contacted, checked if available, passed the arguments,
>>>> collected the
>>>> >> response and according to their procedure left alone to wait
>>>>for > >> another call. The process execution engine however needs
>>>>to > >> invoke the service according to both service specific
>>>>information > >> and the process specific information.
>>> > >>
>>>> >>
>>>> >>
>>>> >> Having just the service specific information in a model
>>>> covers only
>>>> >> one part of the picture and I think it is fine as long as
>>>> that model
>>>> >> is a pure service model. However I find it difficult to > >>
>>>>understand that the SOA RM TC model is a SOA reference model
>>>>when > >> it does not include other concepts of SOA.
>>>>Unfortunately it seems > >> that
>>>> we cannot
>>>> >> get to the point where we could agree on a minimal set of
>>>> supported
>>>> >> SOA concepts by a model to be the SOA RM. We do not have
>>>> to and I do
>>>> >> not want to argue with you or anybody else in SOA RM TC. I
>>>>am > >> just trying to see how our works can fit together in a
>>>>most
>>>> efficient way.
>>>> >> We obviously need more time to better understand each
>>>> others thoughts
>>>> >> and ideas and I strongly believe that a constructive
>>>>respectable > >> discussion is helpful for everybody.
>>>> >>
>>>> >>
>>>> >>
>>>> >> By the way, do you know what I am supposed to do to get my
>>>> messages
>>>> >> to the SOA RM list. In spite of that I am the SOA RM TC
>>>>observer > >> I get a faliure notice whenever I send a note to
>>>>the SOA RM.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Goran
>>>> >>
>>>> >>
>>>> >>
>>>> >> ----- Original Message -----
>>>> >>
>>>> >> From: Duane Nickull
>>>> >>
>>>> >> To: Matt MacKenzie ; goran.zugic@xxxxxxxxxxxxx ; MATHEWS,
>>>> Tim ; Sally
>>>> >> St. Amand ; frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 5:02 PM
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> Goran:
>>>> >>
>>>> >>
>>>> >>
>>>> >> The service layer enables the process layer over top of
>>>> it, however
>>>> >> during runtime, services do not know if they are part of a
>>>> process or
>>>> >> being called individually (it would generally be a bad
>>>> idea to try to
>>>> >> maintain the overall state of a process within each
>>>> service, although
>>>> >> it could be done). For maximum repurposing of services,
>>>> it would be
>>>> >> better to have the service as a simple slave to the
>>>>processes > >> that may use it.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Accordingly, we made a decision that BPM, Orchestration,
>>>> choreography
>>>> >> is not a core part of the RM for SOA. We generally seem to
>>>>agree > >> that many SOA implementations will include a layer of
>>>>BPM over top.
>>>> >> We are only addressing the SOA model, not the model for
>>>>the > >> underlying or overarching layers.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I have a PPT that explains this in more detail if you are
>>>> interested.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> Duane
>>>> >>
>>>> >>
>>>> >>
>>>> >> *******************************
>>>> >>
>>>> >> Adobe Systems, Inc. - http://www.adobe.com
>>>> >>
>>>> >> Vice Chair - UN/CEFACT http://www.uncefact.org/
>>>> >>
>>>> >> Chair - OASIS SOA Reference Model Technical Committee
>>>> >>
>>>> >> Personal Blog - http://technoracle.blogspot.com/
>>>> >>
>>>> >> *******************************
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Matt MacKenzie [ mailto:mattm@xxxxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 12:51 PM
>>>> >>
>>>> >> To: goran.zugic@xxxxxxxxxxxxx; MATHEWS, Tim; Sally St.
>>>>Amand; > >> frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> Process orientation is only one of multiple potential
>>>>integration > >> with service oriented architecture. SOA-RM is
>>>>laying the
>>>> foundation
>>>> >> for durable architecture based on the core concept of
>>>>service > >> orientation. We recognize that process oriented
>>>>architecture is > >> a natural fit with service orientation...but
>>>>so are things
>>>> like event
>>>> >> orientation.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> -matt
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: goran.zugic@xxxxxxxxxxxxx [ > >>
>>>>mailto:goran.zugic@xxxxxxxxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 3:36 PM
>>>> >>
>>>> >> To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand; > >>
>>>>frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better
>>>> >>
>>>> >>
>>>> >>
>>>> >> I think that SOA RM has done good job documenting
>>>> well-known service
>>>> >> related concepts and defining some new ones.
>>> > >>
>>>> >>
>>>> >>
>>>> >> I do not see other details besides service and
>>>>service-related > >> concept definitions in the current SOA RM
>>>>committee draft
>>>> right now.
>>>> >> I look forward to seeing the completion of the model you
>>>> are working
>>>> >> on with the bottom-up approach.
>>>> >>
>>>> >> Business, business processes and collaboration aspects
>>>>of > >> business are important to address in the model what is
>>>>not the > >> case
>>>> with the
>>>> >> current content of the SOA RM committee draft. By a
>>>> business process
>>>> >> I mean a generic business process entity which has common
>>>> components
>>>> >> (activities, decisions, etc) and relationships between
>>>> them that can
>>>> >> be used to model a business process in any environment
>>>> regardless of
>>>> >> what business we support and technology we use. I agree
>>>>with > >> Sally that a link between business processes and
>>>>services should
>>>> be one of
>>>> >> key requirements any SOA reference model should try to meet.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I am not sure what SOA with services brings to business
>>>> when the link
>>>> >> between the business processes and services and overall
>>>>business > >> process semantics in the SOA context are not
>>>>considered to be > >> important aspects in a SOA-based reference
>>>>model.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Goran
>>>> >>
>>>> >> -----Original Message-----
>>>> >>
>>>> >> From: MATHEWS, Tim [ mailto:tmathews@xxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 5, 2005 12:34 PM
>>>> >>
>>>> >> To: 'Matt MacKenzie', 'Sally St. Amand',
>>>> frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better "Componentization"
>>>> >>
>>>> >> Matt - I am not sure what point you are trying to make by this?
>>>> >> I agree with your premise of a bottom up effort, as this was
>>>> one of the
>>>> >> operating assumptions that was made from the beginning.
>>>> >>
>>>> >>
>>>> >>
>>>> >> But, I am confident it is the business environment that
>>>>is > >> independent from the reference model.
>>>> >>
>>>> >>
>>>> >>
>>>> >> TM
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Matt MacKenzie [ mailto:mattm@xxxxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 11:58 AM
>>>> >>
>>>> >> To: Sally St. Amand; frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better "Componentization"
>>>> >>
>>>> >> Sally,
>>>> >>
>>>> >>
>>>> >>
>>>> >> A reference model actually needs to be a bottom up effort.
>>>> We leave
>>>> >> the ever so popular ?top-down? approach to folks like ebSOA J
>>>> >>
>>>> >>
>>>> >>
>>>> >> We?re creating a vocabulary and general understanding of
>>>> what I hope
>>>> >> we can call a discipline of computer science in the future.
>>>> >> This means, we need a durable reference model that is not
>>>> dependent
>>>> >> on the current business environment.
>>>> >>
>>>> >>
>>>> >>
>>>> >> -matt
>>>> >>
>>>> >>
>>>> >>
>>>> >> From: Sally St. Amand [ mailto:sallystamand@xxxxxxxxx]
>>>> >>
>>>> >> Sent: Monday, December 05, 2005 10:19 AM
>>>> >>
>>>> >> To: frank.mccabe@xxxxxxxxxxxxxx
>>>> >>
>>>> >> Cc: soa-rm@xxxxxxxxxxxxxxxxxxxx
>>>> >>
>>>> >> Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM
>>>>Draft > >> for Better "Componentization"
>>>> >>
>>>> >>
>>>> >>
>>>> >> Frank
>>>> >>
>>>> >>
>>>> >>
>>>> >> This is in response to your request on last week?s
>>>> conference call,
>>>> >> if anyone has comments speak now. I also think that the
>>>>recent > >> comments on clarifying sections are a reflection of
>>>>my issues > >> with the specification.
>>>> >>
>>>> >>
>>>> >>
>>>> >> I agree with the majority of points made/described in ver 10.
>>>>My > >> issues are with what is not in this draft. Based on Fig 1
>>>>the Refe!
>>>> >> rence Model is guided by Reference Architectures,
>>>>Concrete > >> Architectures, Profile & Related Models. They in
>>>>turn account for > >> requirements, motivation & goals. This is
>>>>creating a
>>>> Reference Model
>>>> >> from the bottom up. I believe a Reference Model should
>>>> reflect a top
>>>> >> down approach.
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> The Reference Model needs to reflect the environment,
>>>>the > >> strategy and the priorities of the
>>>>business/mission/collaboration.
>>>> This will
>>>> >> impact the construction of services. A service is a
>>>> business task or
>>> > >> activity that is realized through technology. The draft
>>>> does a good
>>>> >> job of describing how that realization happens. But it
>>>>doesn?t > >> provide a sufficient link between processes and
>>>>services.
>>>> >> The draft makes the point that the central focus of! SOA
>>>> is the task
>>>> >> of business function?getting something done. A business
>>>>process > >> is made up of tasks and activities to achieve a goal
>>>>(getting
>>>> something
>>>> >> done). The concept of creating the service from the tasks
>>>>and > >> activities in a process is important. For example, where
>>>>on the > >> continuum of fine grained to coarse grained should a
>>>>particular > >> service be; this will affect interaction,
>>>>reusability.
>>>> >> The relationship between processes and services needs to be
>>>>in > >> the Reference Model.
>>>> >>
>>>> >>
>>>> >>
>>>> >> While I saw that there is a note saying the glossary is still
>>>>in > >> flux, since one of the objective of the Reference Model
>>>>is a > >> vocabulary, having less in the glossary might be a
>>>>better option.
>>>> >> Is semantic integration a guiding principle of SOA?
>>>> >>
>>>> >>
>>>> >>
>>>> >> With respect to conformance there needs to be business results.
>>>> >> That is an SOA should provide demonstrable mission
>>>> accomplishments,
>>>> >> e.g. ROI, match a competitors distribution channel. SOA is
>>>>not a > >> technology. Conformance should provide operational
>>>> accomplishments,
>>>> >> these should be measurable.
>>>> >>
>>>> >>
>>>> >>
>>>> >> Sally
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> !
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >
>>>>
>>>>
>>>>
>>>> _________________________________________________________________
>>>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>>> Subscribe/Unsubscribe/Config:
>>>> http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>>> Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
>>>> http://ontolog.cim3.net/wiki/ To Post:
>>>> mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>>>
>>>>
>>>
>>>
>>>_________________________________________________________________
>>>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>>Subscribe/Unsubscribe/Config:
>>>http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>>Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
>>>http://ontolog.cim3.net/wiki/ To Post:
>>>mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>
>>
>>
>>_________________________________________________________________
>>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>>Subscribe/Unsubscribe/Config:
>>http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>>Shared Files: http://ontolog.cim3.net/file/
>>Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
>>mailto:ontolog-forum@xxxxxxxxxxxxxxxx
>>
>
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Subscribe/Unsubscribe/Config:
>http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/ To Post:
>mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)
--
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Unsubscribe/Config:
http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (015)
|