Populate index with vocabularies from (non-DSL) file contents

[mchlrch]

Same goal as described in #14, but using another approach. It should be possible to use existing vocabularies in the mapping-dsl by dropping a file with RDF serialization of the vocabulary in the mapping project.

For example N-Quads for SKOS: https://github.com/zazuko/rdf-vocabularies/blob/master/ontologies/skos.nq

[mchlrch]

A (small) subset of the SKOS vocabulary would be specified in the DSL as follows:

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

    classes
        Concept

    properties
        notation
}

In the N-Quad file linked above (skos.nq), we can find the following statements.

Concept is-a Class, defined-by http://www.w3.org/2004/02/skos/core ontology.

<http://www.w3.org/2004/02/skos/core#Concept> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2002/07/owl#Class> <http://www.w3.org/2004/02/skos/core#> .
<http://www.w3.org/2004/02/skos/core#Concept> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://www.w3.org/2004/02/skos/core> <http://www.w3.org/2004/02/skos/core#> .

notation is-a Property, defined-by http://www.w3.org/2004/02/skos/core ontology.

<http://www.w3.org/2004/02/skos/core#notation> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Property> <http://www.w3.org/2004/02/skos/core#> .
<http://www.w3.org/2004/02/skos/core#notation> <http://www.w3.org/2000/01/rdf-schema#isDefinedBy> <http://www.w3.org/2004/02/skos/core> <http://www.w3.org/2004/02/skos/core#> .

I saw that the Prefix-Label for the vocabulary is unfortunately not defined in the ontology itself, so we will have to provide that somehow alongside the ontology. Maybe something like _index.nq can be used, as it contains metadata about the ontologies, also Prefix-Label and Prefix-IRI

[ktk]

@mchlrch we do that separately, see https://github.com/zazuko/rdf-vocabularies/issues/27

[ktk]

Ah I did not read that properly, you did find the file :)

[nnamtug]

Here an update for documentation purpose:

The basic idea to provide objects on Xtext index. Xtext does this in order to make EObjects referenceable. The "only" thing is to look into the projects org.eclipse.xtext.*.ecore and turn into a copycat (says Christian Dietrich from xtext). The catch: This topic simply covers every topic that eclipse has to offer in this area: osgi, xtext, emf, guice, maven, tycho.

In order to check the source project from xtext, install eclipse for commiters and checkout all the xtext projects (needs github account and time).

So I turned into a copycat and provided these modules:

• fanin.nq:
  • inspired by org.eclipse.xtext.ecore, but with an own EMF-Resource
  • model defined in bare Ecore NqFanin.ecore with a genmodel. Bare Ecore is required in order to tweek the generated artifacts.
  • text to model transformation (parsing) is done in the implementation of the EMF Resource RealNqFaninResourceImpl.java
  • in order to get the customized EMF resource bootstrapped, don't forget to register its ResourceFactory in the plugin.xml
  • Build the fanin-model with MWE2 workflow GenerateNqFaninModel.mwe2
  • the maven build includes generating nqfanin-items
  • the generated plugin.xml configures the generated EMF-Resource implementation. In order to get the specific parsing included, the resourcefactory has always to be replaced. For documentation purposes, I integrated this in the GenerateNqFaninModel.mwe2
  • Standalone Support is provided for *.nq files
• fanin.nq.nqfanin.test
  • enables testing for parsing, emf-setup for nqfanin (including standalone setup)
• fanin.nq.nqfanin.ui
  • inspired by org.eclipse.xtext.ui.ecore
  • this project is basically empty. all the functionality is provided by the parent project.
• dsl
  • import NqFanin in RdfMapping.xtext and therefore also in GenerateRdfMapping.mwe2
• dsl.common
  • common stuff like utils extracted from dsl-project
  • supports reuse from EMF-centric modules

Limitation This approach is valid for publishing EMF from files in Xtext index. This makes these models referencable from Xtext grammars. If an nq-file changes, the index gets updated on save. This solution can be re-used for any type of file based fanin. But: Reading data from another resource than a file, e.g. a REST resource, is not covered at all. I assume it would be even quite different. Finding such a solution would probably require a serious amount of engineering.

Assessment This solution...

• covers the requirement of referencing elements from outside xtext within in RdfMapping-DSL
• is sustainable, due to the similarity to xtext.*.ecore projects
• using federated models implies introducing a domain layer in order to decouple fanin from fanout

[nnamtug]

Next steps:

• include real parsing of nq-files (replace current dummy implementation)
• properly integrate federated elements in DSL and generators

[nnamtug]

Notes on navigation into nq-editor:

1. parsing, store locationInformation as adapter ( GrammarToDomainConverter, see where using PositionAdapter)
2. publish locationInformation in IEObjectDescription ( NqFaninResourceDescriptionStrategy extends DefaultResourceDescriptionStrategy --> userData)
3. in editor opener, read locationInfo ( NqFaninEditorOpener, using @Inject IResourceDescriptions, PositionAdapter )

[nnamtug]

Notes on RdfMappingCore.ecore: Instances of RdfClass and RdfProperty now may origin from different sources. Since there are references to these elements without the same syntax for any source type. This implies to have a common ecore model, the RdfMappingCore.ecore. It is referenced by NqFanin.ecore and RdfMapping.ecore. Both concrete models provide instances of RdfMappingCore.

[mchlrch]

If Eclipse is the target runtime platform for the editor, this approach works well.

As the focus is shifting more and more towards the LSP based editor, we want to avoid adding integrations with Eclipse runtime.

I'm closing this issue

(the code of this prototype is on branch issue_72_index)