-
Notifications
You must be signed in to change notification settings - Fork 1
Home
will be major rework to properly support entity update. Code will stay in its own branch-0.50. For things to do, see Milestone 0.50
- Entity model: to be reworked, shrinked and needs implementation of interfaces
- SemanticText and NLP stuff: has implementations and it's quite stable. Maybe for SemanticText we should remove Sentence and just keep a list of words
- provenance: to be removed and put in TraceProv repository
OpenEntity should be a generic interface to support a variety of knowledge bases:
- The API should be simple, without Java generics and deep class hierarchies
- Immutable classes should be used wherever possible
- Classes should be expected to have missing values, either because not offered by the knowledge base (it might not support concepts) or too expensive to fetch (for example, batch read of entities might not be available).
- Implementations will not be concerned with serialization, so API users will be able to use any serialization framework they prefer. TODO we might provide how-to examples/interfaces with Jackson in a separate module, though
- Provenance will be handled in the separate TraceProv repository. Since currently most projects will depend on TraceProv, utility functions should go there, in OdtUtils class
Immutability prevents hard to find errors and in most cases doesn't actually hit perfomances. Thus interfaces shouldn't have methods for setting properties and most implementation classes should be immutable. To this end, implementations will leverage classes and principles of Google Guava immutable collections
Immutable objects require shallow cloning of the object anytime a modification is needed. To easily clone objects with many fields, since Java clone() is deprecated, we can use Kryo :
Kryo kryo = new Kryo();
SomeClass someObject = ...
SomeClass copy2 = kryo.copyShallow(someObject);
Another alternative is using immutables.org to generate builders, as already done in TraceProv
Class implementations instead of 'set' methods should thus have 'with' methods that always return a new copy, i.e.:
semText.with("Ciao")
will produce a new SemanticText object with text "Ciao" and all other parameters equals to the original semText object.
To copy the object of an existing interface static 'copyOf' methods are provided, i.e.:
SemanticText.copyOf(ISemanticText semText)
will return a new object copied from semText OR the very same semText if it is an instance of SemanticText (and is thus immutable)
TODO We need builder classes to create a new object by inexpensively modifying several parameters of an immutable object. So to have calls like
myObj.builder().withFoo("hello").withBar("world").build();
that create only ONE new object instead of two (one for each with call).
To mark nullable variables we used the @Nullable tag from from JSR-305. Latest IDEs can recognize the tag and warn about unchecked null usage. Wherever possible we also marked Refine nullable fields. We consider all the objects as non null unless marked otherwise. todo how to configure default value?
Example usage:
@Nullable String s;
TODO - probably using the Optional class of Guava would be better, but adopting it would cause compatibility problems with existing code