Re: Interoperability discussion for the Framework Report

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,
****************************************

Received on Tuesday, 5 May 2009 12:36:00 UTC