The conclusion of ticket #337 (comment) is that there is a M to N relationship between the dc:language of multilingual resources and the text processors that might process the annotation body and/or target.

Therefore the following proposal for the definition of the processing language property:

"This property represents the relationship between the language of the resources (Body or Target) and the text processors or classes of text processors that may process the resources for rendering, indexing or any NLP processing."

• Consequently I propose that the verbose representation of this property should include <language, processor_class, processor_id> tuples.
  It is recommended to use a vocabulary for processor classes like: textual_representation, audio_representation, visual_representation (i.e. image), text_indexing, nlp_processing
  Example:

processingLanguage:{
  {language: [“en”, “fr”, “ro”],  processor_class: “textual_representation”},
  {language: “en”,  processor_class: “text_indexing”, processor_id : “<snowball_indexer_uri>”},
  {language: “ro”,  processor_class: “audio_representation”, processor_id : “<TTS_RO_uri>”}
}

• The minified representation could be compliant with the current specification, with the meaning that all text processors (all types) should use the same processing language.
• There are 2 open questions:

a. Should this property be named “processing”?
b. Should this information be embedded within the annotations (model) or in the protocol (own http request)?