saul Getting some feedback

@Rahgooy let me just say thank you for your awesome job in adding the SpRL example. It is definitely now a core part of the examples modules. Yet definitely we should&will try to improve it, even more. While there has been a great deal of good work, we have to strive everyday to make things much better. I want to get a little sense about your experience while working on this example; I have a few questions for you:

Was it your first time using Scala (or any other functional language) ?
Where did find the most difficulty in using Saul? (documentation? datastructures?)
What did you enjoy the most while using Saul?
Do you have any suggestions on what can be added and how it can be improved? (or what do you want to see in Saul?)

Sep 13 '16 19:09 danyaljj

Thanks, and I'm very happy about working as a team with you and other contributors of Saul. I really enjoy the team work and I'm looking forward to participate more in this project.

Was it your first time using Scala (or any other functional language) ? Yes, I'm new to Scala and even Java, and I didn't have any experiences with functional programming before.
Where did find the most difficulty in using Saul? (documentation? datastructures?) Working with TextAnnotation features is not easy, for these reasons:
1. Achieving trivial things have a very cumbersome style, for example if you want to get the third token of a Sentence you should write s.getSentenceConstituent.getTextAnnotation.getToken(2)
2. Working with features that use more than one Constituents, like path, using Edison is not clear. Here is the FeatureExtractor declaration:
```
public interface FeatureExtractor {
Set<Feature> getFeatures(Constituent var1) throws EdisonException;
String getName();
}
```
  As you can see there is no assumption in the contract about the Constituent. But many of the FeatureExtractors, like ParsePath do assume that the Constituent is a part of a Relation, and I think it is ambiguous.
3. Some features are designed and implemented by a specific usage in mind. Take ParseHeadWordPOS for example. It finds the head word and its POS tag:
```
features.add(DiscreteFeature.create("hw:" + ta.getToken(head).toLowerCase().trim()));
features.add(DiscreteFeature.create("h-pos:" + WordHelpers.getPOS(ta, head)));
```
  as you can see, there is two problems in this implementation. First, it returns two features, the head word and the POS tag, which I think we should separate them. Second, it appends some strings to the features which makes life harder, when you need the exact value of the feature.

Sep 15 '16 03:09 Rahgooy

What did you enjoy the most while using Saul? The abstraction that it provides when you think about the problem, is what I enjoyed the most. Thanks to its clear separation of concerns, it helps you to think in a systematic and abstract way. You think about the Data Model, without concerning about the underlying data or what you want to do later on(classification or anything else).

Sep 15 '16 03:09 Rahgooy

Do you have any suggestions on what can be added and how it can be improved? (or what do you want to see in Saul?) The most important part from my view is the feature extraction. I think it needs more attention and to add more features. I think we need more documentation as well, tiny examples about features and how they can be used can be very helpful.

There is nothing about parameter tuning is Saul, as far as I know, so we can work on this as well.

Sep 15 '16 03:09 Rahgooy