OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uima message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: UIMA TC Call Today (June 8)



A couple of discussion points for today
=========================================

1. Compliance
===========
I think we have a global issue that seems to emerge from time-to-time centered about responsibilities of a framework with respect to compliance/enforcement.

I believe we do NOT want the spec to define tasks, functions for a framework but rather make declarations for what it means to be UIMA compliant in general or define lesser or narrower shades of UIMA compliance. This is wholly independent of how compliance would be determined or whether or not any given framework would choose to determine it or act on it.

So, we want to make statements like

"A UIMA Service must produce an output XCAS that satisfies its post-condition given an input XCAS that satisfies its preconditions"

...

"where post-conditions have this syntax and semantics ...."


If a UIMA service does not do so (how this is determined is not an issue for the specification) then we would consider that it is not specifically "behavior metadata compliant" (or some more simply-stated compliance category). A reason to be more specific is so that it is easier for application developers to choose to ignore various warnings or levels of incompliance.

So the point here is that we do not want the specification to define tasks, functions for a framework but rather just make declarations for what it means to be UIMA compliant or to satisfy more specific shades of UIMA compliance, however they may be determined.

2. We need a simpler meta-data specification
==========================================
In our discussion I think we should try to cleanly separate the classes of things we want to say in the behavioral meta-data (section 5.4.2) from how they are expressed. So I think we should

1. understand and vote on the elements in section 5.4.2 and then
 
2. identify and vote on different levels of expressivity (whether or not to have them), for example, a. Types-Only, b. Types and Views, c. Types and Features, c. Constraints.

3. Vote on the expression language itself for each of the levels of expressivity chosen in 2. So for example if we decide to include the "constraints" level of expressivity, what would be the language? OCL as-is?

4. A separate question is whether or not we can use OCL as a underlying  specification language to define the semantics of the less expressive alternatives.


------------------------------------------------------------------------
David A. Ferrucci, PhD
Senior Manager, Semantic Analysis & Integration
Chief Architect,  UIMA
IBM T.J. Watson Research Center
19 Skyline Drive, Hawthorne, NY 10532
Tel: 914-784-7847, 8/863-7847
ferrucci@us.ibm.com
------------------------------------------------------------------------
http://www.ibm.com/research/uima  


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]