Difference between revisions of "Modeler:9/Namespaces"
m |
m |
||
| Line 1: | Line 1: | ||
= Namespace = | |||
So called namespaces can exist between projects or departments, or anything else where a different set of concepts or language is used. The financial department may have a different set of facts than the logistics department. For CaseTalk this is not a problem, yet the users may need support for these different namespaces when merging CaseTalk models. | So called namespaces can exist between projects or departments, or anything else where a different set of concepts or language is used. The financial department may have a different set of facts than the logistics department. For CaseTalk this is not a problem, yet the users may need support for these different namespaces when merging CaseTalk models. | ||
= Fact Expressions = | |||
Therefor CaseTalk, the professional edition and higher, supports this notion through so called namespaces. Every model created in CaseTalk immediately generates its own Namespace Identifier. Adding fact expression to this model, will all be marked with this identical identifier. | Therefor CaseTalk, the professional edition and higher, supports this notion through so called namespaces. Every model created in CaseTalk immediately generates its own Namespace Identifier. Adding fact expression to this model, will all be marked with this identical identifier. | ||
= Merge models = | |||
When merging models in CaseTalk, the models from difference namespaces are merged. Expressions merged into an existing model are by default locked, being they originate from a different namespace. Users may unlock these upon request, which severs the link it represented. | When merging models in CaseTalk, the models from difference namespaces are merged. Expressions merged into an existing model are by default locked, being they originate from a different namespace. Users may unlock these upon request, which severs the link it represented. | ||
= Reference = | |||
An overview of expressions originating from a different namespace can be found in the [[Modeler:9/ExpressionViewer | Repository Window]]. | An overview of expressions originating from a different namespace can be found in the [[Modeler:9/ExpressionViewer | Repository Window]]. | ||
The Object/Fact Types are not considered from this namespace, only the fact expressions themselves. While a Object/Fact Type has underlying expressions from a different namespace, they are considered non-editable. Users should break the namespace reference before able to edit the Object/Fact Types involved. | The Object/Fact Types are not considered from this namespace, only the fact expressions themselves. While a Object/Fact Type has underlying expressions from a different namespace, they are considered non-editable. Users should break the namespace reference before able to edit the Object/Fact Types involved. | ||
Revision as of 13:22, 11 November 2019
Namespace
So called namespaces can exist between projects or departments, or anything else where a different set of concepts or language is used. The financial department may have a different set of facts than the logistics department. For CaseTalk this is not a problem, yet the users may need support for these different namespaces when merging CaseTalk models.
Fact Expressions
Therefor CaseTalk, the professional edition and higher, supports this notion through so called namespaces. Every model created in CaseTalk immediately generates its own Namespace Identifier. Adding fact expression to this model, will all be marked with this identical identifier.
Merge models
When merging models in CaseTalk, the models from difference namespaces are merged. Expressions merged into an existing model are by default locked, being they originate from a different namespace. Users may unlock these upon request, which severs the link it represented.
Reference
An overview of expressions originating from a different namespace can be found in the Repository Window.
The Object/Fact Types are not considered from this namespace, only the fact expressions themselves. While a Object/Fact Type has underlying expressions from a different namespace, they are considered non-editable. Users should break the namespace reference before able to edit the Object/Fact Types involved.