Eddie Epstein wrote:
On 5/25/07, Thilo Goetz <[EMAIL PROTECTED]> wrote:
Technically, the proposal consists of a new built-in type and new
built-in
index as follows.
- a type uima.cas.FsVariable that inherits from uima.cas.TOP with
features
name:String, type:String and value:TOP.
The feature called "value", as type TOP, can only hold a reference to
another FS. So, it is not possible to create an FsVariable with a
double valued feature, or with an Integer feature, etc. As you say, it
is an "FS variable".
I'm still a little fuzzy about the scope of what can be done with this
proposal. Looking back at the previous discussion, Adam said:
I think one use case is the "singleton" use case. You could define a
"global variable" called myapp.documentMetadata and set its value to
an instance of myTypeSystem.DocumentMetadata. Then all your
annotators could access it by getting the value of this global
variable.
The application has to create a custom type,
myTypeSystem.DocumentMetadata, which is good because it is documented
in the descriptors. So the FsVariable is a mechanism to get to the
single instance of a custom type.
I admit that the alternative of creating a custom set index for a type
is a bit much for most users.
Yes, that is *the* use case. People want to create document metadata. They
often do this by adding new features to DocumentAnnotation, which leads to
problems, mainly in conjunction with the JCas (because everybody creates a
different cover class for the DocumentAnnotation, but only one of those cover
classes is actually loaded; this problem will not go away until we have a
separate class loader for each annotator. We're one step closer to at least
being able to have that with Marshall's ongoing work on JCas class loading)
Jorn said:
Imagine an Annotator which is a spam filter, it has to
put a tag to the CAS which say spam or no_spam.
The document language is also an example for a global variable.
These examples would not be covered because the FsVariable can only
point to another FS, not hold an arbitrary value; correct?
True, but Joern didn't really say he was talking about string values.
You could also imagine having a DocumentLanguage FS that holds one or
more string valued features.
- a built-in set index over FsVariable, sorted by the name feature.
The APIs to define and access these critters would look as follows.
// Declare a new global variable/singleton FS
declareFsVariable(String name, Type type)
What happens when a variable is declared?
First we check if a FSVariable object with the given name already exists
in the FSVariable index. If it does, we throw an exception. If not, we
create a new FSVariable with the name feature set to the name parameter,
the type feature set to type.getName() and value set to null. This we
put in the index.
// Check if a variable of that name exists
isFsVariable(String name):boolean
// Get the value of variable
getFsVariableType(String name):Type
This just returns the String value for Type, yes?
Not sure what you mean. It checks if a variable with name exists, and
if yes, returns the type object corresponding to the type feature of the
FSVariable. If no such variable exists, either return null or throw an
exception (I'd favor the latter in this case).
// Get all variables of a given type
listFsVariables(Type type):List
What exactly is the List returned?
A list of Strings, containing all names of FSVariables declared for
the input type.
And finally, looks like I missed a couple of pretty crucial methods.
// Retrieve a certain FSVariable value. May return null.
getVariableValue(String name):FeatureStructure
// Set a variable value.
setVariable(String name, FeatureStructure fs):void
Those also would throw an exception if the variable did not exist, or, in
the latter case, was of the wrong type.
Thanks,
Eddie
