uima message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: UIMA TC Call Today (June 8)
- From: David Ferrucci <ferrucci@us.ibm.com>
- To: David Ferrucci <ferrucci@us.ibm.com>
- Date: Fri, 8 Jun 2007 10:48:03 -0400
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]