I am trying to implement (yet another:-) variant of the FeatureStructure interface of common.unify.
Why can I set a feature to any Object but Variable only unifies with Unifiable? Seems somewhat inconsistent to me - please inform me on your intuitions. I think I would prefer if I could also set the value of Variable to any Object.
Some feedback also (since I am writing anyway):
Otherwise your interface seems to fit nicely with my own requirements as well. (Although, I don't see that I can use the static class Unifier)
On simplification could be to avoid passing the substituation around explicitely, since it is really only needed for variables (if I understand you correctly). An other alternative would be to assume that Variable would take care of the subst. "behind the scene", e.g. in a global constraint heap. This would mean that if I don't implement Variable I get a more natural unify-method without a null-parameter.
Best regards,
--Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You are correct about the issue of setting features values as Objects and Variables only unifying with Unifiables. I had intended to change that so that feature values would have to be Unifiables to make it consistent, but I haven't been able to spend any time on coding for some time now and didn't get to it. Since we weren't feeling too strongly either way, I'm fine with making it so that Variables can unify with Objects. (Gann, if you are reading this, do you agree?) If so, it's an easy fix that I can do tomorrow and check it in.
The Unification stuff is interesting... I agree that it would be nice to not have to pass Substitution objects around. I'm worried that a global heap would have problems for multi-threaded programs and would prefer something more modular.
Do you have any suggestions for making this work?
I'm glad that the interfaces work well for you. Please do let us know of any further suggestions that you think of, and if you are interested in developing the interfaces yourself, we can see about getting you developer access.
BTW, what are you working on?
Cheers,
Jason
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unifiable: It seems like a restriction to me to "force" values to implement Unifiable. Then they need a unify-operation although they really dont use it - they can only handle equals anyway right? Isn't it better to generalize the unify-operation to accept Object as parameter?
Variables: I don't have an opinion here yet (I decided to think about those things later...) There seems to be many variants around on variables/constraints. Do you intend to base your work on any particular variant? (If yes: Do you have some web/paper references to share?)
Substitution: What I had in mind was a thread-safe Singleton-construction...but not everybody likes that. Another alternative would be to have two operations unify/1 and unify/2. Yet another alternative would be to start thinking about a listener-interface for the FS/Unifiable class.
developing APIs: at some point it would be great to help with the common API. But I think I will experiment "locally" in my own code a little more first. What is your position on "backwards compatibility" for opennlp.common by the way?
Current work: we have started up a project called nlpFarm that will contribute to the opennlp-packages (Jason: I sent you an offline mail about our plans earlier this spring). We will use feature structures in various ways. Right now I am rewriting an existing partial chartparser using the opennlp interfaces.
I have not posted a formal mail about the startup nlpFarm since our homepage is not really finished...but it will be shortly. I hope :)
Regards,
--Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Its fine for me to have use Object as a parameter. I'll take care of that when I get back to coding next week.
Our unification scheme is not based on anything other than Gann's original stab at the problem which I later modified to try to clean it up a bit. But it still isn't particularly efficient, and it certainly isn't the best way of doing it. It works for what we need at the moment, but I would love to have someone make a solid effort at just this aspect.
The perspective on backwards compatibility is that things are still quite fluid. If you start using the interfaces, we can work together to stabilize things as until now I've pretty much hacked them around as much as I've needed to without much worry about others. Now that you are using the interfaces, I'll be more careful and make sure that major changes are okay. Probably what is best at this point it to set some definite goals for stabilizing the interfaces by some time based on the needs of both of our projects.
Glad to hear things are moving forward with nlpFarm! Let me know when you have your homepage up, and I'll add nlpFarm to the project list if you wish.
-j
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just realized I get into problems since you don't use "atomic" feature structures as well as compound. What is your way of unifying two "feature paths" that lacks values in both unified structures? I think we may perhaps need to allow for "atomic structures" to deal with this...unless you have a better solution. If this is needed I can give you a sketch for an updated API that includes that (and the other stuff we have discussed).
--Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I am trying to implement (yet another:-) variant of the FeatureStructure interface of common.unify.
Why can I set a feature to any Object but Variable only unifies with Unifiable? Seems somewhat inconsistent to me - please inform me on your intuitions. I think I would prefer if I could also set the value of Variable to any Object.
Some feedback also (since I am writing anyway):
Otherwise your interface seems to fit nicely with my own requirements as well. (Although, I don't see that I can use the static class Unifier)
On simplification could be to avoid passing the substituation around explicitely, since it is really only needed for variables (if I understand you correctly). An other alternative would be to assume that Variable would take care of the subst. "behind the scene", e.g. in a global constraint heap. This would mean that if I don't implement Variable I get a more natural unify-method without a null-parameter.
Best regards,
--Lars
You are correct about the issue of setting features values as Objects and Variables only unifying with Unifiables. I had intended to change that so that feature values would have to be Unifiables to make it consistent, but I haven't been able to spend any time on coding for some time now and didn't get to it. Since we weren't feeling too strongly either way, I'm fine with making it so that Variables can unify with Objects. (Gann, if you are reading this, do you agree?) If so, it's an easy fix that I can do tomorrow and check it in.
The Unification stuff is interesting... I agree that it would be nice to not have to pass Substitution objects around. I'm worried that a global heap would have problems for multi-threaded programs and would prefer something more modular.
Do you have any suggestions for making this work?
I'm glad that the interfaces work well for you. Please do let us know of any further suggestions that you think of, and if you are interested in developing the interfaces yourself, we can see about getting you developer access.
BTW, what are you working on?
Cheers,
Jason
Hi again,
Some comments on your previous mail:
Unifiable: It seems like a restriction to me to "force" values to implement Unifiable. Then they need a unify-operation although they really dont use it - they can only handle equals anyway right? Isn't it better to generalize the unify-operation to accept Object as parameter?
Variables: I don't have an opinion here yet (I decided to think about those things later...) There seems to be many variants around on variables/constraints. Do you intend to base your work on any particular variant? (If yes: Do you have some web/paper references to share?)
Substitution: What I had in mind was a thread-safe Singleton-construction...but not everybody likes that. Another alternative would be to have two operations unify/1 and unify/2. Yet another alternative would be to start thinking about a listener-interface for the FS/Unifiable class.
developing APIs: at some point it would be great to help with the common API. But I think I will experiment "locally" in my own code a little more first. What is your position on "backwards compatibility" for opennlp.common by the way?
Current work: we have started up a project called nlpFarm that will contribute to the opennlp-packages (Jason: I sent you an offline mail about our plans earlier this spring). We will use feature structures in various ways. Right now I am rewriting an existing partial chartparser using the opennlp interfaces.
I have not posted a formal mail about the startup nlpFarm since our homepage is not really finished...but it will be shortly. I hope :)
Regards,
--Lars
Its fine for me to have use Object as a parameter. I'll take care of that when I get back to coding next week.
Our unification scheme is not based on anything other than Gann's original stab at the problem which I later modified to try to clean it up a bit. But it still isn't particularly efficient, and it certainly isn't the best way of doing it. It works for what we need at the moment, but I would love to have someone make a solid effort at just this aspect.
The perspective on backwards compatibility is that things are still quite fluid. If you start using the interfaces, we can work together to stabilize things as until now I've pretty much hacked them around as much as I've needed to without much worry about others. Now that you are using the interfaces, I'll be more careful and make sure that major changes are okay. Probably what is best at this point it to set some definite goals for stabilizing the interfaces by some time based on the needs of both of our projects.
Glad to hear things are moving forward with nlpFarm! Let me know when you have your homepage up, and I'll add nlpFarm to the project list if you wish.
-j
I just realized I get into problems since you don't use "atomic" feature structures as well as compound. What is your way of unifying two "feature paths" that lacks values in both unified structures? I think we may perhaps need to allow for "atomic structures" to deal with this...unless you have a better solution. If this is needed I can give you a sketch for an updated API that includes that (and the other stuff we have discussed).
--Lars