Re: Interoperability discussion for the Framework Report

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