- From: <paola.dimaio@gmail.com>
- Date: Tue, 5 May 2009 13:48:43 +0100
- To: Gary Berg-Cross <gbergcross@gmail.com>
- Cc: Chamindra de Silva <chamindra@opensource.lk>, Renato Iannella <renato@nicta.com.au>, public-xg-eiif <public-xg-eiif@w3.org>
- Message-ID: <c09b00eb0905050548s1df82e25vc82c77eff35ece4f@mail.gmail.com>
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, ****************************************
Received on Tuesday, 5 May 2009 12:49:25 UTC