Skip to content

Ideas on derivation #235

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 32 commits into
base: main
Choose a base branch
from
Draft

Ideas on derivation #235

wants to merge 32 commits into from

Conversation

enikao
Copy link
Contributor

@enikao enikao commented Feb 4, 2024

based on #167

Very unfinished, just scribbling down my thoughts.
This draft PR is meant as a place to collect comments.

@@ -90,6 +90,11 @@ IDerived "0..*" -> "1..*" Node: base
Each derived node references one or more base nodes.
Any (base) node can have none or more derived nodes.

[horizontal,labelwidth=12]
QUESTION:: Should a derived node also be able to refer to features inside a node? Or do we leave that for specific classes implementing `IDerived`?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the example below, the PropertyViolation points to a specific feature.

Assume the following concepts:

concept Person [id=P, key=pers]
  property firstName: string [id=PF, key=firstN]
  property lastName: string [id=PL, key=lastN]

concept EmptyNameViolation implements IDerived, IViolation [id=ENV, key=emptyNameV]
  property message: string [id=ENVM, key=msg]
  reference property: Property [id=ENVP, key=prop]

Original model contains instance:

Person A [id=2]
  firstName = "John"
  lastName = ""

Validation derived model contains instance:

EmptyNameViolation B [id=5]
  message = "lastName is empty!"
  base = --> A[id=2]
  property = --> lastName[id=PL]

@@ -90,6 +90,11 @@ IDerived "0..*" -> "1..*" Node: base
Each derived node references one or more base nodes.
Any (base) node can have none or more derived nodes.

[horizontal,labelwidth=12]
QUESTION:: Should a derived node also be able to refer to features inside a node? Or do we leave that for specific classes implementing `IDerived`?
QUESTION:: The assumption is that derived nodes can have children that are not derived nodes.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Derived nodes can have any kind of features, including children that might or might not implement IDerived.

@@ -134,6 +139,9 @@ We need to omit the parameter if we don't want to limit the depth.
==== Result
{chunk} containing all derived nodes according to `nodeIds`, `languages`, and `depthLimit` parameters.

[horizontal,labelwidth=12]
QUESTION:: The `depth:Limit` describes the depth of the retrieved nodes (derived nodes may be full trees), the next line suggests that `depthLimit` applies to the node id's sent. Needs clarification.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea is:

  1. We select the same original nodes as with Bulk API retrieve
  2. For all these nodes, we find their derivations (if available)
  3. For all derivations, we return the derivations and all descendants thereof with infinite depth.
    The assumption is that derived nodes only contain other nodes that are part of the derived information.

@@ -143,6 +151,8 @@ Does NOT include the definition of <<{serialization}.adoc#UsedLanguage, UsedLang


== Possible derivation backends
[horizontal,labelwidth=12]
QUESTION:: The repository that is referred to is this always the repository where the opriginal model is stored, or could oit be a different (i.e. derivation processor specific) repository?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formally the derivation backend implementation is independent of the repository implementation, i.e. they don't need to be the same "service". (In practice in makes a lot of sense to couple them, though.)

Derived models are part of the same repository as the original model in the sense that they share one id-space, and can refer to each other.

@@ -270,6 +280,9 @@ package M3 {
}
----

[horizontal,labelwidth=12]
QUESTION:: Should the `PropertyValidation` also point to the Property instance in the M2 model being validated, and not just to the node that contains the property?
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See remark above.

@ftomassetti
Copy link
Contributor

I am not sure if there is a better place to write these comments, but reading the current document on derived models I had these questions/comments:

  • Can other sources be involved in creating a derived node (e.g., external data)? So should we say that a derived node is produced by examining existing nodes (both "original nodes" and other derived nodes) plus, potentially, external sources?
  • Can we have a derived partition or just other nodes?
  • What about changing the term base node in source node?
  • Should derived nodes have some sort of marker to figure out which derivation produced them? For example, an annotation
  • Should derivations have a name or some identifier?
  • Why do we need the IDerived interface? Can't I derive any node I want? For example, I may want to use derive nodes to de-sugar code, without having to mark all of my expressions or statements as implementing IDerived

@enikao
Copy link
Contributor Author

enikao commented Mar 15, 2024

Can other sources be involved in creating a derived node (e.g., external data)? So should we say that a derived node is produced by examining existing nodes (both "original nodes" and other derived nodes) plus, potentially, external sources?

Yes, as long as the processor creating the derived nodes takes care of interacting with the external source.

Can we have a derived partition or just other nodes?

I'm not sure I understand. We can have a derivation of any node, not only partitions.

What about changing the term base node in source node?

I don't really mind; I think we used this term base already at other places for this idea.

Should derived nodes have some sort of marker to figure out which derivation produced them? For example, an annotation

Derivations are defined by their ava, i.e. a language. That might be enough of a marker -- or not.

Should derivations have a name or some identifier?

Derivations in sense of derived nodes are marked by implementing IDerived.
Derivations themselves are defined by their ava, i.e. a language.
Do we need more identification?

Why do we need the IDerived interface? Can't I derive any node I want? For example, I may want to use derive nodes to de-sugar code, without having to mark all of my expressions or statements as implementing IDerived

IDerived connects the derived node to its base. Without that, how do we know from what we derived it?
We can have an EvaluationResult implements IDerived that refers to the evaluated expression.
The EvaluationResult can contain arbitrary complex sub-nodes to e.g. describe the execution time of each sub-expression. These sub-nodes don't need to implement IDerived (even though it might make sense, because we can connect them uniquely to a base node).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joswarmer Can you also commit a PDF version of this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a PNG version next to the PowerPoint

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, figured the PowerPoint had more than the one figure :)

A base model can be an _original_ or a _derived_ model.

processor::
A _processor_ is a component that provides/calculates derived nodes for nodes in a base model.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

{C|Sh}ouldn't a processor be associated to a set of languages that a base model is supposed to conform to? An “instance” of a processor would then be associated to a particular base model.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think a processor should have a set of partitions for which it derived nodes. Which of the nodes in the partitions will havederived nodes is up to the processor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants