Re: Interoperability discussion for the Framework Report

Paola, Chamindra, Renato et al.

I hadn't thought of the issue of revising the gap section as you suggest
since I saw the Framework document as starting with a discussion of the ER
Domain.

>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?
Thniking about it in light of your question I do think that the first issue
is one of gaps and mis-matches throughout the entire ER domain withing the
pragmatics you are interested in.

Here's the way I'm thinking about it.  One might say there is a
topic/subject of "missing persons".  Informatic people used to speak of a
Universe of Discourse for the topic you are discussing and we might be
discusing  "missing persons".  But we might also say that  "missing persons"
is a Domain within the larger ER Domain.  That's the way I am thinking and
so there may be Domains withing the current ER Domain that are missing in
the sense that people haven't developed them informatically to the point
where they serve the pragmatic need of finding people.

In a way our framework document had a very (very) loose look at the overall
domain and you might have in the gap analysis some discussion of Domain
gaps.  But the strong connection, I believe, is between the pragmatics and
Domain.  Domains are vast and we structure a view of them based on the
pragmatics of what we are trying to get accomplished in them.  In a way we
are looking at a pragmatic-domain intersect.  We ask, "what do I need to
know about people in order to find them if they are missing?"  But also ask
many other questions about people such as their skills, medical condition,
role etc.   It is the union of these answers that makes up our Person
Domain.  The pragmatics of say banking might have a different union with
some of these.

So we come back to the question of how to address this in the gap analysis.
One idea is to have the pragmatic-domain intersect first, then
semantics-conceptual and last syntax, the easiest and where some spend most
of their time, but I think we might spend most of the time in the middle
area of semantics-conceptual given that we have provided a focus to the
pragmatic-domain.
Gary Berg-Cross,Ph.D.
gbergcross@gmail.com
http://ontolog.cim3.net/cgi-bin/wiki.pl?GaryBergCross
SOCoP Executive Secretary
Principal in Semantic Technology, EM&I
Potomac, MD
301-762-5441

On Tue, May 5, 2009 at 8:48 AM, <paola.dimaio@gmail.com> wrote:

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


--