Include descriptions from vocabularies in code-assist

[mchlrch]

Provide "tooltip" for properties and classes in the code-assist, show description from vocabularies.

See Label Provider

This also requires to expand the grammar, in order to include the descriptions in the vocabularies.

[ktk]

Ideally we would have two things here: The label & the description

[nnamtug]

We need to discuss the concrete syntax. For now, the description can optionally be added using brackets:

But this may be misleading, since the declaration of a RdfClass may be followed by a value (used for CSV). Any ideas? And do we need multiline descriptions here? @mchlrch

However, the description is technically transformed into a Documentation. So RdfHoverDocumentationProvider is introduced. The result looks like this (sorry for the poor quality, this literally is a screen shot since the tooltip disappears before taking a software-screenshot in ubuntu):

[mchlrch]

This will be be used mainly when XRM vocabularies are generated from existing ontologies. But it can also be used with new vocabularies, that get created during the mapping process itself.

@nnamtug I think something like an omnimap would be a good fit here.

For example for skos:broader https://prefix.zazuko.com/skos:broader it could look like this:

vocabulary skos {
  prefix "skos" "http://www.w3.org/2004/02/skos/core#"

  properties
      broader "broad-er" {
          "label": "has broader",
          "comment": "Broader concepts are typically rendered as parents in a concept hierarchy (tree).",
          "definition": "Relates a concept to a concept that is more general in meaning."
      }

And then build a simple Documentation that concatenates all values from the map, ignoring the keys:

has broader

Broader concepts are typically rendered as parents in a concept hierarchy (tree).

Relates a concept to a concept that is more general in meaning.

I think that way we have the flexibility to later also take the keys from the map into account if needed, maybe to display them, or filter/sort on the keys if necessary.

The Strings can be multiline. But I think that Xtext STRING covers that already, no?

[nnamtug]

Yes, Xtext STRING can already be multiline, so that is fine.

The OmniMap is now introduced. It refuses duplicated keys or keys having sourrounding whitespaces.

When integrating an OmniMap into a specific DSL element, simply declare known keys in OmniMapKeyDefinition.xtend. This will be used to provide code completion and sorting the values in the Hoverprovider. But however, the user is still allowed to add unknown keys to the OmniMap.

Example: The entries { "label", "description" } are wellknown - they will therefore appear in the code completion and put first in the hover. Try it by opening editortest.xrm:76 and of course the incoming references to Employee

[mchlrch]

Added the OmniMap for the Datatype as well. Datatypes are declared in the Vocabulary alongside classes and properties.

Modified the OmniMapKeyProposalGenerator to return quoted Strings, e.g "label"

[mchlrch]

The entries { "label", "description" } are wellknown - they will therefore appear in the code completion and put first in the hover

Aligned to rdfs:comment, so the wellknown entries are now { "label", "comment" }

Sample tooltip/hover shown on "Employee" in the mapping:

OmniMap description on "Employee" in the vocabulary:

vocabulary employee {
    prefix "employee" "http://example.com/employee"

    classes
        Employee {
            "foobar" : "some additional description",
            "label": "Worker",
            "comment": "a person employed for wages or salary, especially at non-executive level",
            "similar": "labourer"
        }