You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org> on 2012/04/25 16:28:18 UTC
[jira] [Created] (UIMA-2391) Uima type merging for string subtypes
not working
Charles de Saint-Aignan created UIMA-2391:
---------------------------------------------
Summary: 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
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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262095#comment-13262095 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
I've now figured out a counter example showing a failure for the 1st analogy above. This would happen if annotator written to use Foo with feature range A created some A's which were not B's, and assigned it to the slot it thought was holding "A"s. These objects wouldn't have any added B features, so if later another annotator tried to use the value as a B, it would fail.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262003#comment-13262003 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
Re: avoiding runtime exception: this would not happen because (1) the type system description would no longer be using the Allowed Values (therefore, it would allow all values), and (2) the additional user code you would invoke whenever you needed to check, would compare the value against a parameterized set of allowed values, which you could specify at runtime.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261985#comment-13261985 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
Here's a work-around. The obvious one is to replace the range spec with uima.cas.string (in other words, deleted the allowed-values, and allow any values).
I presume you have some intent to restrict this, though. It sounds like you want it restricted in some "core" implementation to some set , e.g. a,b,c, but are willing to have other users arbitrarily extend this with other values.
You could put the set of allowed values into a parameter, and then write a small bit of extra code to do whatever checking you think is appropriate, whenever you think is appropriate. Would this approach be reasonable for your use case?
> 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
>
> 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
[jira] [Closed] (UIMA-2391) Uima type merging for string subtypes
not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor closed UIMA-2391.
--------------------------------
Resolution: Won't Fix
Charles reports he's found a workaround. We won't make the change suggested for the reasons discussed in the comments.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262037#comment-13262037 ]
Charles de Saint-Aignan commented on UIMA-2391:
-----------------------------------------------
Are you saying that if we just don't put in any allowed values, then all values will be allowed? I'd rather have some level of control and not have to put in some additional code to do that.
On another note, it still seems like a bug to me that UIMA does not behave this way. I think adding this in would make it consistent with respect to the ability to merge features.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262102#comment-13262102 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
Another kind of workaround - don't rely on type merging. Instead, adopt a strategy for combining annotators that allows constructing whatever common type system you need. This would allow you to have a common shared type system, and if a configuration required additional "allowed values", you could edit the descriptor and add them (after checking manually, that doing so wouldn't break some other annotator that might have been relying on the more limited set). Type merging was envisioned more for the case where the XML descriptors for an annotator couldn't be modified.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261936#comment-13261936 ]
Charles de Saint-Aignan commented on UIMA-2391:
-----------------------------------------------
Adam, I see your point about the potential that the system could have enums representing these values. However, the use of enums in this case makes it very difficult to extend the system, so I think given that type merging is possible (and actually necessary for the kind of extension we want to do), it should exist for string subtypes as well.
Regarding your second analogous case, I don't think it applies since rangeType is not valid in the case of string subtypes, right?
I think I have found the place in the code where the merging should happen so I am attempting a patch.
> 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
>
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262643#comment-13262643 ]
Charles de Saint-Aignan commented on UIMA-2391:
-----------------------------------------------
Marshall, I've tried to remove all allowedValues in order to essentially allow all values. However, this instead allows no values. I want to come up with a solution that does not require a major rearchitecture of the core in order to make it extensible. The only viable solution I have seen so far is the given patch to UIMA to enable allowedValue merging. I'm not entirely following your other potential workarounds.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Adam Lally (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261891#comment-13261891 ]
Adam Lally commented on UIMA-2391:
----------------------------------
Currently, code using the core type system can rely on the fact that instances of the Type can only ever be a, b, or c. They can be used like enums in this way. If we implement merging this way we would break that. Are we sure we want to do that? Code built off the core type system would not be expecting a value "d" and might not know what to do with it.
An analogous case might be - what happens if I merge two type systems that 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.
Or course, I might just be biased against extending the scope of type merging since I was never happy it existed in the first place. :)
> 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
>
> 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
[jira] [Updated] (UIMA-2391) Uima type merging for string subtypes
not working
Posted by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Charles de Saint-Aignan updated UIMA-2391:
------------------------------------------
Attachment: UIMA-2391.patch
Attached is a patch to uimaj-core which merges allowed values.
> 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
[jira] [Issue Comment Edited] (UIMA-2391) Uima type merging for
string subtypes not working
Posted by "Adam Lally (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261891#comment-13261891 ]
Adam Lally edited comment on UIMA-2391 at 4/25/12 6:23 PM:
-----------------------------------------------------------
Currently, code using the core type system can rely on the fact that instances of the Type can only ever be a, b, or c. They can be used like enums in this way. If we implement merging this way we would break that. Are we sure we want to do that? Code built off the core type system would not be expecting a value "d" and might not know what to do with it.
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.
Or course, I might just be biased against extending the scope of type merging since I was never happy it existed in the first place. :)
was (Author: alally):
Currently, code using the core type system can rely on the fact that instances of the Type can only ever be a, b, or c. They can be used like enums in this way. If we implement merging this way we would break that. Are we sure we want to do that? Code built off the core type system would not be expecting a value "d" and might not know what to do with it.
An analogous case might be - what happens if I merge two type systems that 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.
Or course, I might just be biased against extending the scope of type merging since I was never happy it existed in the first place. :)
> 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
>
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Charles de Saint-Aignan (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261988#comment-13261988 ]
Charles de Saint-Aignan commented on UIMA-2391:
-----------------------------------------------
Sorry attached the patch before reading your comment, Marshall. You are correct that we have some intent to restrict so the first workaround would not do the trick. I'm not sure how you would intend the second workaround to work...how would we be able to avoid the runtime exception from UIMA when we provide an allowed value outside of the "core" set? Is there an extension point I don't know about?
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262691#comment-13262691 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
How to allow all values:
Change the type description which currently says
Types:
SubTypeOfString with some allowed values
T1: F1 has range of SubTypeOfString
to
T1: F1 has range of uima.cas.string
Then, feature F1 can be assigned any string; UIMA does no checking.
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-2391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261849#comment-13261849 ]
Marshall Schor commented on UIMA-2391:
--------------------------------------
Cases to consider:
a,b,c merged with a,b,c,d ==?? a,b,c,d
a,b,c merged with a,b ==?? a,b,c
a,b,c merged with d,e,f ==? nothing or a,b,c,d,e,f ?
In the last case, if the merge contains only those allowed values that are in both lists, then it is empty. If it contains allowed values that are in either list, then it is all of them.
It seems to me that the idea of merging is to support running multiple independently developed things together, then perhaps the right answer for a,b,c + d,e,f is a,b,c,d,e,f
What do others think?
> 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
>
> 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
[jira] [Commented] (UIMA-2391) Uima type merging for string
subtypes not working
Posted by "Marshall Schor (JIRA)" <de...@uima.apache.org>.
[ 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