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] My stab at an SOA-RM concept map


<quote>
Not sure about the direction of some of these arrows.
</quote>

It depends on what visualisation tool/method you are using...back to the
confcall debate... ;-)

I do not understand the arrows to mean anything more than illustrate that
the words imply a sentence structure of SVO (Substantive-Verb-Object)

More precisely it will be an ontology that constrains meaning, not
semantics, but in our context I'm wondering whether we should make *any*
association between semantics and policy, except to say textually (and this
is not a formal proposal for wording) "Policy needs to be understood as a
mix of explicitly defined service description and the meanings implicit in
other objects and associations within the model..." I know, it's a bit
flaky...

-Peter

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: 01 June 2005 18:31
To: Behera, Prasanta
Cc: Matthew MacKenzie; peter@justbrown.net; SOA-RM
Subject: Re: [soa-rm] My stab at an SOA-RM concept map

Not sure about the direction of some of these arrows.

Assuming that

A ---part of--> B

means A is a part of B, then I think

Data Model ---part of--> Semantics

reflect my pov.

Continuing, this....

Policy ---part of--> semantics

Semantics ---defined-by--> Ax. x ---part of--->Semantics

Actually, I am not that part-of is the correct predicate. View-of seems
closer to the truth.

For example, what is the data model? The question is non-trivial because
there is a close synergy between the data model and the process model. And a
part-of relationship suggests separable components.

Frank




On Jun 1, 2005, at 9:09 AM, Behera, Prasanta wrote:

> How about this?
>
> Semantic ---part of ---> Data Model
> Semantic ---constrain --> Policy
> Semantic ---define------> Policy
> Semantic ---constrain---> Service (not too sure for this one).
>
> Does this work?
>
> Thanks,
> /Prasanta
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Wednesday, June 01, 2005 8:55 AM
> To: Matthew MacKenzie
> Cc: Behera, Prasanta; peter@justbrown.net; SOA-RM
> Subject: Re: [soa-rm] My stab at an SOA-RM concept map
>
> Actually, I am not happy with the constrain word here.
>
> The data-model, for example, is not constrained by the semantics of 
> the service -- it *is* part of the semantics.
>
> Frank
>
> On Jun 1, 2005, at 8:50 AM, Matthew MacKenzie wrote:
>
>
>> Ok, I'm happy with constrain as well.
>>
>> -matt
>> Behera, Prasanta wrote:
>>
>>
>>
>>> That would be the term of choice for me too.
>>> (Sorry. Didn't get a chance respond early)
>>>
>>> Thanks,
>>> /Prasanta
>>>
>>>
>>> -----Original Message-----
>>> From: Peter F Brown [mailto:peter@justbrown.net] Sent: Tuesday, May 
>>> 31, 2005 6:56 PM
>>> To: 'SOA-RM'
>>> Subject: RE: [soa-rm] My stab at an SOA-RM concept map
>>>
>>> Surely semantics "constrain" rather than "govern" or "define"?
>>> Specifically,
>>> they constrain meaning within a specified domain ontology
>>>
>>> -Peter
>>>
>>> -----Original Message-----
>>> From: Behera, Prasanta [mailto:pbehera@visa.com] Sent: 31 May 2005
>>> 20:03
>>> To: Matthew MacKenzie; Francis McCabe
>>> Cc: SOA-RM
>>> Subject: RE: [soa-rm] My stab at an SOA-RM concept map
>>>
>>> #1: Can u expand a little bit on the semantics of "govern"?  
>>> Semantics
>>> "define" and "govern" policy.
>>>
>>> #2: The relationship between "Data Model" and "Services" -- should 
>>> it be more of a association type (line instead of a arrow)
>>>
>>> Thanks,
>>> /Prasanta
>>>
>>> -----Original Message-----
>>> From: Matthew MacKenzie [mailto:mattm@adobe.com]
>>> Sent: Tuesday, May 31, 2005 9:13 AM
>>> To: Francis McCabe
>>> Cc: SOA-RM
>>> Subject: Re: [soa-rm] My stab at an SOA-RM concept map
>>>
>>> Having some problems with arrows in this tool, but I added another 
>>> relationship to contract (attached).
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>





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