Re: [uima] UIMA TC Votable Issues for July 20 Telecon

[Adam Lally <alally@us.ibm.com>]

Hi,

Good question.  As written now
I think it is not the case that that referenced types are automatically
included in a component's input.  However I can see that this would
be useful.

For example if a component declared
a requiredInput or optionalInput "Person" which had a feature
birthDate of type "Date", it seems annoying to force the component
developer to also declare "Date" as an input.  On the other
hand, if there were a complex type with lots of references to other types,
a component might not want to see all of them.  So I can imagine use
cases where we might not want to automatically included all referenced
types (worst case you could end up dragging in the whole CAS).  

So as you suggest it might make sense
for this to be an option that can be specified in the Behavioral Metadata
XML.  The downside of that is that it adds more complexity, and we
are trying to keep the type-level Behavioral Metadata as simple as possible.

One thing we could do is to use the
notion of "containment" references that's in UML and Ecore.  These
languages allow an object to be contained in another, instead of just referenced
from it.  An object can't have more than one container at a time.
 If the container object is deleted so is the contained object.  We
could decide that containment relationships can never be filtered out.
 So in the above example if the birthDate feature were declared to
be a containment reference, then the developer wouldn't have to declare
Date as an input type.  For non-containment relationships, the component
developer would have to explicitly declare all the types if it required
them.  This seems to me like a natural interpretation of containment
relationships.

Regards,
  -Adam

_____________________________
 Adam Lally
 Senior Software Engineer 
 UIMA Framework Lead Developer
 IBM T.J. Watson Research Center
 Hawthorne, NY, 10532
 Tel: 914-784-7706,  T/L: 863-7706
 alally@us.ibm.com

Yoshinobu KANO <kano@is.s.u-tokyo.ac.jp>

07/23/2007 05:26 PM

Please respond to
kano@is.s.u-tokyo.ac.jp

To	uima@lists.oasis-open.org
cc
Subject	Re: [uima] UIMA TC Votable Issues for July 20 Telecon

Hi,

I read through the Behavioral Metadata Proposal,
and I am not sure about a detailed issue related to Post/Preconditions.

When we specify a type X which has a feature whose range is 
FeatureStructure of another type Y,
then type Y (and other referred types recursively) will automatically be
included,
or we should specify every type explicitly?
I hope both is possible by some flags in the descriptor.

Excuse me if I missed descriptions about it in the document.

Thanks,

-Yoshinobu

--
Yoshinobu KANO
kano@is.s.u-tokyo.ac.jp
Tsujii Laboratory, the University of Tokyo

Adam Lally wrote:
> 
> Everyone,
> 
> Six new web ballots have been posted on the OASIS UIMA TC webiste.
>  Please register your votes.   A summary of the issues is
listed below. 
>  If all the votes pass then I think we're done with the Behavioral
> Metadata for now.
> 
> Thanks,
> -Adam
> 
> 
> All refer to the attached document BehavioralMetadataProposal_v4.
> 
> *1. **Type-Level XML structure.  *Accept Section 4.1 "Type
Names" of the 
> Behavioral Metadata Proposal, which proposes the XML syntax for 
> declaring Behavioral Metadata at the type level (e.g. inputs types
X and 
> Y and creates type Z).
> 
> *2. Constraint-Level XML structure. * Accept OCL as the constraing
> language for UIMA Behavioral Metadata, and accept Section 4.2 "OCL
> Expressions" of the Behavioral Metadata Proposal, which proposes
the XML 
> syntax for specifying OCL expressions as part of the Behavioral Metadata
> XML.
> 
> *3. View XML structure*.  Accept section 4.3 "Views"
of the Behavioral 
> Metadata Proposal, which proposes the XML syntax for declaring 
> Behavioral Metadata for analytics that operate on views.  Note
this vote 
> includes the following that have been added to the Proposal since
the 
> last telecon:
>         a. Analytics can specify /optional/ input
views as well as 
> /required/ input views.
>         b. Analytics may use OCL expressions to
specify the views that 
> they operate on, for cases where referring only to the Sofa Type of
the 
> View is insufficient.
> 
> *4. Including Features for "Modifies".  *Accept section
4.4 "Specifying 
> Which Features are Modified" of the Behavioral Metadata Proposal,
which 
> proposes the XML syntax for declaring the names of the features that
an 
> analytic may modify.
> 
> *5. Precondition, Postcondition, Projection Condition XML Structure.
>  *Accept section 4.5 "Specifying Preconditions, Postconditions,
and 
> Projection Conditions" of the Behavioral Metadata Proposal, which
> proposes the XML syntax for directly declaring preconditions, 
> postconditions, and projecton conditions in Behavioral Metadata.
> 
> *6. Defer Open Issues to a later date.  *Resolve to defer the
open 
> issues in Section 7 of the Behavioral Metadata Proposal until after
we 
> produce a preliminary specification draft.
> 
> 
> _____________________________
> Adam Lally
> Senior Software Engineer
> UIMA Framework Lead Developer
> IBM T.J. Watson Research Center
> Hawthorne, NY, 10532
> Tel: 914-784-7706,  T/L: 863-7706
> alally@us.ibm.com