Re: Interoperability discussion for the Framework Report

some additional thoughts

I have not yet investigated the following hypothesis that is surfacing

"could defining the sy, sem or pr dimension a priori point to  different
domain perspectives into the interoperability gap?"

what I mean is: is it possible that given a case of lack of interoperablity,
the root causes of the gap are to be found in different domains?

I dont know if this question is worth pursuing, but could be worth some
tests

PDM

On Tue, May 5, 2009 at 1:35 PM, <paola.dimaio@gmail.com> wrote:

> Thanks Gary
>
> if I understand you right
>
> are you suggesting to swap the steps, so that the first step of the gap
> analysis should be: domain definition (as it would be in any ontology
> engineering)?
>  and then work out the synt, sem and prag issues?
>
> That may well be a good idea ,
> (In fact I think the entire document draft contains uselful info that needs
> to be sorted and logically ordered)
>
> the only thing one would have to be careful is that by narrowing down the
> domain too early one could not capture interdomain gaps, so to speak
>
> but that can be addressed in further steps I guess
>
>
>
>
> On Tue, May 5, 2009 at 1:24 PM, Gary Berg-Cross <gbergcross@gmail.com>wrote:
>
>> Paola et al,
>>
>> Here are some of my thoughts visa-via this gap interoperability discussion
>> using a simple  example to see that it makes sense and a fllow on discussion
>> of pragmatics.
>>
>> P>this is how I think gap analsyis works for us:
>>
>> P>take any example/case where system A is not interoperable with system B
>> then ask, why are they not interoperable?
>> look at syntax, semantics, pragmatics aspects
>> P>of each system and spot where the 'gap' is, ie where the two systems do
>> not share the representation/use
>>
>> In a way the first reason that systems are not  interoperable is that they
>> are not covering the same domain of interest.  If they have overlap on the
>> domain topics then they need to share the same semantics for a given
>> pragmatic reason (intention is to find and save missing people) and then be
>> able to exchange messages in a syntax they can each parse.  An example for
>> missing persons is sharing domains for people but also for location.  If
>> systems don't agree on representing where things are located in a
>> geographical area (and when) they aren't going to be able to help find and
>> rescue people.
>>
>> Both pragmatics and semantics  are concerned with the use of data: what
>> the data means in different systems or contexts; how it relates to other
>> data; and what rules govern its use. In short, both pragamatics and
>> semantics make something useable information  and transforms it from mere
>> “data”. Current technologies support a variety of ways to enable a
>> correct syntactic integration by passing valid instance data.  So
>> increasingly there are fewer gaps at the syntactic level.
>>
>> iIntegrating the semantics of the underlying systems still is difficult
>> because information is created for, and are applied to, specific situations
>> - which one might think of as the pragmatic level - my purpose in having
>> this system, what it will help with.
>>
>> Engineers integrating enterprise application systems and their application
>> services have to know the meaning of the low-level data structures in order
>> to implement a semantically correct integration .  Typically not enough
>> structural information about "situations" is adequately captured or
>> represented to do this. Without such situational knowledge to integrate data
>> producers and data consumers, the chances of misunderstanding and
>> misapplication increase.
>>
>> I think we need to scope  our approach to pragmatics and keep it simple.
>> We need a pragamatic way of addressing these pragmatics.  At first blush the
>> pragmatics we are concernd with are macro level and are like the intentions
>> to "save people", "limit damage", "coordinate resources".  These are the
>> topics we discuss in emergency management that integrate efforts and are
>> something like information pragmatics.  At this point we don't want to
>> confuse this with a finer grained pragmatics that apply to individual agents
>> which would get messy.
>>
>>
>> Gary Berg-Cross
>>
>>
>> On Tue, May 5, 2009 at 3:36 AM, <paola.dimaio@gmail.com> wrote:
>>
>>>
>>>> >>
>>>> >> Do these definitions cover the gap between
>>>> >> - systems
>>>> >> and
>>>> >> - interop standards
>>>> >> - to match a needed use-case?
>>>> >
>>>>
>>>> I think it is important to cover these, at least in the context of the
>>>> W3C charter, which generally is focused on driving interop standards.
>>>>
>>>
>>> this is how I think gap analsyis works for us:
>>>
>>> take any example/case where system A is not interoperable with system B
>>>
>>> then ask, why are they not interoperable?
>>>
>>> look at syntax, semantics, pragmatics aspects
>>> of each system and spot where the 'gap' is, ie where the two systems do
>>> not share the representation/use
>>>
>>> narrow it down specifically to a domain cluster, for example medical vs
>>> communication domain
>>> identify domain specific issues (terminology, policy)
>>>
>>> the analysis above will help to decide what steps need to be taken to
>>> bridge the gap
>>>
>>> In addition to the dimensions above, we may want to find additional
>>> factors for our gap analysis method:
>>>
>>> for example the systems are not interoperable because:
>>>
>>> people
>>> processes
>>> policy
>>> system
>>> language
>>> etc
>>>
>>>
>>> you can add freely if there are things we left out
>>>
>>>
>>>> >>
>>>> >> If by systems you mean systems in use, then I would say that falls
>>>> under
>>>> >> the pragmatic bracket
>>>>
>>>> We need that pragmatic bracket! :-)
>>>> >
>>>> > in the note, we define three dimensions (at least, in fact  4) for
>>>> > addressing an interoperability gap (the (syntactic, semantic,
>>>> pragmatic and
>>>> > conceptual)
>>>> >
>>>> > then we project these dimensions across different fields of interop,
>>>> > communication, medical, etc etc
>>>> >
>>>> > so I would say that matrix should help us define the 'interoperability
>>>> gap'
>>>> > which is a broad description of possibly everything that does not
>>>> > interoperate, down to a few specific factors.
>>>> > I would say that any use case can be broken down
>>>> >
>>>> > give me one  or two example of interop gap that you are referring to,
>>>> and I
>>>> > ll try to map the case with the proposed method of analysis, in fact
>>>> we can
>>>> > map all of them if you want
>>>>
>>>> Let me put a disclaimer first on not being an expert on ontology
>>>> mapping.
>>>>
>>>> OK take CAP for example. If we were looking at an alerting use-case
>>>> the first would be to define the ontology for emergency alerting. Next
>>>> would be to identify existing standards (or interop formats) that can
>>>> cover that scope, like CAP + other interop standards in alerting.
>>>>
>>>> 1) The first gap would be that between our ontology and the standards.
>>>>
>>>> 2) Next you would document alerting systems that support the format
>>>> (e.g. Sahana does) and the gap would be to those alerting systems that
>>>> do not support any alerting interop standard. A more subtle gap would
>>>> be the actual tested level of support of that standard.
>>>>
>>>> Chamindra
>>>>
>>>
>>>
>>>
>>> --
>>> Paola Di Maio,
>>> ****************************************
>>>
>>>
>>
>>
>> --
>> x
>>
>>
>
>
> --
> Paola Di Maio,
> ****************************************
>
>


-- 
Paola Di Maio,
****************************************