Add proper DocumentMetaData support about dkpro-cassis HOT 4 OPEN

The following cases are possible:

• CAS contains exactly one org.apache.uima.jcas.tcas.DocumentAnnotation annotation
• CAS contains more than one org.apache.uima.jcas.tcas.DocumentAnnotation annotation (in DKPro Core, this would be considered a bug, but there is nothing in UIMA Core preventing this scenario)
• first or second case, just that it is actually a subclass of DocumentAnnotation (DKPro Core actually uses a subclass, namely DocumentMetaData)

The document annotation is often the first one created in the CAS, but I wouldn't rely on that. E.g. when a user creates a CAS via uimaFIT in a DKPro Core context and sets the document string, first a DocumentAnnotation is created. This can later be removed and replaced with a DocumentMetaData. I would expect this scenario to have an effect on the ID.

org.apache.uima.jcas.tcas.DocumentAnnotation is "predefined", but contrary to all other predefined types, it is not in UIMA Core. It is defined in a separate JAR and a user could decide to redefine the type as well as use their own custom JCas class with additional fields. DocumentMetaData is not "predefined" - it is a part of the DKPro Core typesystem.

The (J)CAS APIs assume that there is always some document-level annotation of type DocumentAnnotation (or compatible like DocumentMetaData) and return this when CAS.getDocumentAnnotation() is called. Furthermore, they assume that there is a field language in the document annotation which can be accessed via the shorthand CAS.get/setDocumentLanguage() (equiv. to CAS.getDocumentAnnotation().get/setLanguage())

from dkpro-cassis.

Right now, I do not serialize it at all which is not so good.

from dkpro-cassis.

@Br0ce I made it so that we do not crash if a type system already defines custom DocumentAnnotation. Can you try out the master?

from dkpro-cassis.

@jcklie tested with and without DocumentAnnotation. Looks good to me.

from dkpro-cassis.