uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marshall Schor (JIRA)" <...@uima.apache.org>
Subject [jira] [Commented] (UIMA-2391) Uima type merging for string subtypes not working
Date Wed, 25 Apr 2012 20:54:17 GMT

    [ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262071#comment-13262071
] 

Marshall Schor commented on UIMA-2391:
--------------------------------------

Some more discussion on if this is a bug, by analogy.

Adam said (above): An analogous case might be - what happens if I merge two type systems that
define the same type with the same named feature (call it Foo.bar) but different range types.
In type system 1, Foo.bar has range type A and in type system 2 it has range type B. Would
you want to say that in the merged type system, Foo.bar could be A or B? Probably not."

If we modify this slightly: assume B is a subtype of A.  Then B has all the features A has,
plus maybe more.  A possible reasonable value for the merged type system would be for Foo.bar
to have range type B.  Currently, UIMA Type merging won't do this either.

The analogy discussed above is a case of a subtype "adding" features to an existing type.
 

The "AllowedValues" attribute is unusual, in that, compared to it's supertype (string), it
"subtracts" possibilities.  So, if you had some kind of merging, you could make a case that
the proper behavior for merging of these things is to subtract the union of their negation
- or in other words, if B has only allowed value "a,b", but type A has "a,b,c", then the proper
behavior is the more restrictive one (a,b).  This would satisfy the constraint that both users
of this would only see (a subset) of the allowed values either had declared.
                
> Uima type merging for string subtypes not working
> -------------------------------------------------
>
>                 Key: UIMA-2391
>                 URL: https://issues.apache.org/jira/browse/UIMA-2391
>             Project: UIMA
>          Issue Type: Bug
>          Components: Core Java Framework
>    Affects Versions: 2.3.1AS
>         Environment: Linux on Power
>            Reporter: Charles de Saint-Aignan
>            Priority: Critical
>         Attachments: UIMA-2391.patch
>
>
> The basic situation is that we are providing a UIMA-based core that other teams can extend
to suit their needs.  As such we are making use of UIMA type merging to allow them to add
new features to existing types.  This approach works fine since JCasGen merges the two definitions
of the given type and produces a superset of the features.  This is well documented here:
> http://uima.apache.org/d/uimaj-2.3.1/references.html#ugr.ref.jcas.merging_types.jcasgen_support

> However, in addition to this, we have the case where we have a string subtype with given
allowedValues - lets say values a, b and c.  The other team wants to extend this type and
have additional allowedValues, say value d.  Ideally, what I would like to do is the following
(which follows the pattern used for adding features):
> Type Definition #1 (provided by core):
>     <typeDescription>
>       <name>com.ibm.Type</name>
>       <description></description>
>       <supertypeName>uima.cas.String</supertypeName>
>       <allowedValues>
>         <value>
>           <string>a</string>
>           <description></description>
>         </value>
>         <value>
>           <string>b</string>
>           <description></description>
>         </value>
>         <value>
>           <string>c</string>
>           <description></description>
>         </value>
>       </allowedValues>
>     </typeDescription>	    
> Type Definition #2 (extension to core):
>     <typeDescription>
>       <name>com.ibm.Type</name>
>       <description></description>
>       <supertypeName>uima.cas.String</supertypeName>
>       <allowedValues>
>         <value>
>           <string>d</string>
>           <description></description>
>         </value>
>       </allowedValues>
>     </typeDescription>
> In this case I wanted UIMA to recognize the two definitions at runtime and allow the
superset of allowedValues.  However, this does not do the trick - at runtime UIMA throws an
exception saying that value d is not an allowed value for com.ibm.Type.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message