Ecore Refs as Edges

[mohamadreza77]

So, I got the fact that we can create our own edges based on defining some EClasses in the ecore file extending the GEdge class. These are so called element-based classes where we do have a dedicated EClass for capturing the details for our edge.
What about ref properties in the ecore file? Can we define edges for them?

For instance, here we say every person has a ref to their mother and father, and as they can be shared, they are not values. Man and Woman are also GNode extending Person. Can we annotate these refs accordingly (to create and have edges for them)?

Thanks!
Mohamadreza

[martin-fleck-at]

Hi @mohamadreza77,

I'm not fully understanding your model structure, could you explain the split between the source model and the graphical model a bit more? Typically, in GLSP we do have a source model (or semantic model) which represents your actual data that come from any type of data source (database, file, etc.). You can think of it as the internal model holding your data (loaded on open, modified through operations and stored again on save). The source model gets translated into the graphical model (or just GModel) for visual representation and interaction on the client-side. So the GModel should mainly contain information that you require on the client-side for rendering the diagram.

For Java-based GLSP servers, you can use EMF to represent and extend the graphical model. However, ideally you still keep the source model and the graphical model separate. To me it seems that you currently might mix that in a single model, i.e., a Person with a mother and father (as semantic element of the source model) together with a node having two edges (representing the Person and the connection to the mother and father node) that is used for visual representation.

[mohamadreza77]

@martin-fleck-at, thanks for your response.

I wasn’t referring to the split between the source model and the graphical model. My question is specifically about the Ecore modeling phase, even before we define any graphical model. At this stage, we design an .ecore file that captures the domain-specific EClasses and their structural features.

For instance, in the workflow example, you defined a WeightedEdge as a dedicated EClass extending graph.GEdge. By annotating this EClass, you enabled the graphical model to render it as a specific kind of edge. This is what I would call an element-based edge, where the edge itself is an EClass.

Now, let’s say I don’t define a new EClass for the edge. Instead, I just define a reference (EReference) directly inside an EClass; for example, a Person has a mother reference pointing to a Woman. This reference could also be visualized as an edge. However, from what I see in your example, it seems that such references need to be backed by a dedicated EClass (like WeightedEdge) in order to appear as edges in the graphical model.

So, my question is:
Is there a way to annotate plain EReferences so they are treated as edges in the graphical model (similar to how it works in GMF with gmf.link annotations)?
Or do we always need to define a dedicated EClass for each edge we want to visualize?

Thanks again!

[martin-fleck-at]

GLSP typically does the transformation from the source model (EMF-based or otherwise) to the graphical Model (GNodes, GEdges, etc.) in the GModelFactory. However, in the example, the source model and the graphical model are the same for simplicity, so there is no need for any factory to be bound since we already have GNodes and GEdges that the client can render. I'm not aware of any annotation that you can do that automatically provides the mapping from references to GEdges in your case. So you either need a custom GModelFactory to translate your already almost-GModel source model into a full GModel or you need to make sure that the source model already uses GEdges.