Property:GeneralDescription
From Odp
This property is of type Text.
Pages using the property "GeneralDescription"
Showing 12 pages using this property.
C | |
|---|---|
| Classification scheme - adjacency list model - to Taxonomy + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the adjacency list model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The adjacency list data model for hierarchical classifications proposes to create an entity which holds a list of items with a linking column associated to their parent items. g column associated to their parent items., The ontology generated will be based on th … The ontology generated will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are mapped to subClassOf relations. gories are mapped to subClassOf relations., 1. Identify the classification scheme item … 1. Identify the classification scheme items which do not have a parent key value, i.e. classification scheme items without parents. 2. For each one of the above identified classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , which are children of cei, by using the parent key values. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Set up the subClassOf relation between Cj and Ci. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items without parent cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Set up the subClassOf relation between Ci class and the root class. ation between Ci class and the root class., … |
| Classification scheme - path enumeration model - to Taxonomy + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the path enumeration model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The path enumeration data model for classification schemes take advantage of that there is one and only one path from the root to every item in the classification. The path enumeration model stores that path as string by concatenating either the edges or the keys of the classification scheme items in the path. e classification scheme items in the path., The generated ontology will be based on th … The generated ontology will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are mapped to subClassOf relations. gories are mapped to subClassOf relations., 1. Identify the classification scheme item … 1. Identify the classification scheme items whose their path enumeration values are equal to their key values, i.e. classification scheme items without parents. 2. For each one of the above identified classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , which are children of cei, by using the path enumeration values. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Set up the subClassOf relation between Cj and Ci. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items without parent cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Set up the subClassOf relation between Ci class and the root class. ation between Ci class and the root class., … |
| CyclicSubClassOf + | Not applicable for refactoring patterns, The ontology before applying the pattern contains an explicitly defined cyclic SubClassOf chain with an arbitrary number of classes Ci (i > 0): ''SubClassOf(A C1) SubClassOf(C1 C2) SubClassOf(C2 C3) ... SubClassOf(Cn A)'', Replacing the cyclic SubClassOf chain with an EquivalentClassesAxiom: EquivalentClasses( A C1 C2 C3 ... Cn), … |
F | |
| Faceted Classification Scheme + | A FCS is defined as: "a set of mutually ex … A FCS is defined as: "a set of mutually exclusive and jointly exhaustive categories, each made by isolating one perspective on the items (a facet), that combine to completely describe all the objects in question, and which users can use, by searching and browsing, to find what they need" [[Community:References/How_to_Make_a_Faceted_Classification_and_Put_It_On_the_Web_3|(Denton, 2003)]]. The following notation is introduced to refer to the elements of a generic FCS in the figure below: * ''Target Domain Concept'' (''TDC'') denotes the domain of discourse. The domain-specific concept targeted by the FCS. * ''Facet_i'' denotes one of the facets of the FCS. * ''F_iTerm_j'' denotes one of the terms of ''Facet_i''. * ''Item_x'' denotes one the items from the domain of discourse (''TDC'') to be classified. n of discourse (''TDC'') to be classified., Generic structure of the [[Submissions:Nor … Generic structure of the [[Submissions:Normalization|Normalization]] ODP used to represent a Faceted Classification Scheme (FCS). [[Image:NormalizationGenericStructure1.png|center|frame|The symbol (≡) denotes an OWL defined class.]] The figure below represents a further generalization of the [[Submissions:Normalization|Normalization]] ODP and introduces the following notation: * '':TDC'' denotes a primitive class representing the domain concept being normalized. * '':Module_i'' denotes a primitive class that represents one of the modules. * '':M_iClass_j'' denotes a primitive class that represents a subset of the module class '':Module_i''. * '':hasModule_i'' denotes an object property that links every module '':Module_i'' to the different subclasses of the target domain concept '':M_iClass_jTDC'' and '':SpecificTDC_x''. * '':M_iClass_jTDC'' denotes a defined class that represents a subset of the target domain concept class '':TDC''. Every class '':M_iClass_jTDC'' is defined based on its relationship to the single corresponding class '':M_iClass_j'' that it is derived from. * '':SpecificTDC_x'' denotes a primitive class that represents a subset of the target domain concept class '':TDC'' and an entity from the domain to be classified. Every class '':SpecificTDC_x'' is described based on its relationship to various classes '':M_iClass_j'' from potentially different modules. As a consequence of this relationship, the classes '':SpecificTDC_x'' could introduce the polyhierarchy scenarios in the ontology model that the [[Submissions:Normalization|Normalization]] ODP aims to manage and untangle. The implementation of a generic defined class '':M_iClass_jTDC'' is given as follows: '':M_iClass_jTDC'' rdf:type owl:Class ; rdfs:subClassOf '':TDC'' ; owl:equivalentClass [ rdf:type owl:Restriction ; owl:onProperty '':hasModule_i'' ; owl:someValuesFrom '':M_iClass_j'' ] . The implementation of a generic class '':SpecificTDC_x'' is given as follows: '':SpecificTDC_x'' rdf:type owl:Class ; rdfs:subClassOf '':TDC'' , [ rdf:type owl:Restriction ; owl:onProperty '':hasModule_i'' ; owl:someValuesFrom '':M_iClass_j'' ] , [ ... rest of existential restrictions on property '':hasModule_i'' for every class '':M_iClass_j'' that participates in the description of '':SpecificTDC_x'' ] . This implementation of the classes '':M_iClass_jTDC'' and '':SpecificTDC_x'' respectively, enable a reasoner to infer and maintain the subsumption relations between a given class '':SpecificTDC_x'' and the various classes '':M_iClass_jTDC'' that it is related to. '':M_iClass_jTDC'' that it is related to., Mapping between the elements in the generi … Mapping between the elements in the generic structure of a Faceted Classification Scheme and the [[Submissions:Normalization|Normalization]] ODP. The table below summarizes the alignment of the elements in the generic structure of both conceptual models. This alignment enables the conversion from a FCS to an OWL DL ontology by applying the [[Submissions:Normalization|Normalization]] ODP: * The first column (leftmost), contains the elements of a generic FCS as introduced in section '''Non-Ontological Resource''' above. * The second column contains the elements of the [[Submissions:Normalization|Normalization]] ODP generic structure as introduced in section '''Ontology''' above. * The third column represents the selected OWL notation for the elements of a generic FCS in the context of the [[Submissions:Normalization|Normalization]] ODP generic structure. * The forth column (rightmost), indicates the OWL implementation chosen for every element. The selection complies with the requirements of the normalization mechanism. [[Image:MappingFCSNormalizationODP.png|center]] Based on the principle of representating each facet of a FCS as a module of the [[Submissions:Normalization|Normalization]] ODP, the underlying ideas behind the mappings in the figure(table) above can be outlined as follows: * The target domain concept ''TDC'' represents the domain of discourse of both a FCS and the [[Submissions:Normalization|Normalization]] ODP. The primitive class '':TDC'' fulfills that role in the normalized ontology. * A facet ''Facet_i'' from a generic FCS corresponds to a module '':Module_i'' in the [[Submissions:Normalization|Normalization]] ODP, therefore it becomes a primitive class '':Facet_i'' in the normalized ontology model. * A facet ''Facet_i'' from a FCS also becomes an object property '':hasFacet_i'' in the normalized ontology, given that for every module '':Module_i'' in the [[Submissions:Normalization|Normalization]] ODP, there is an object property '':has_Module_i''. * From the relationship between facet and module, it follows that a facet term ''F_iTerm_j'' from a FCS maps to a module subclass '':M_iClass_j'' from the [[Submissions:Normalization|Normalization]] ODP. Both elements represents the same notion in their respective conceptual models. A subvidision, a refinement of the facet or module that they complement respectively. Therefore, a facet term ''F_iTerm_j'' from a FCS becomes a primitive class '':F_iTerm_j'' in the normalized ontology. * A facet term ''F_iTerm_j'' from a FCS also produces a defined class '':F_iTerm_jTDC'' in the normalized ontology, given that for every primitive class '':M_iClass_j'' in the [[Submissions:Normalization|Normalization]] ODP, there is a corresponding defined class '':M_iClass_jTDC''. * Every item ''Item_x'' to be classified in the FCS aligns to a class '':Specific_x'' that is automatically classified by a reasoner in the [[Submissions:Normalization|Normalization]] ODP. Therefore, every element ''Item_x'' is represented as a primitive class '':SpecificTDC_x'' in the normalized ontology. pecificTDC_x'' in the normalized ontology., … |
P | |
| Pattern for re-engineering a classification scheme, which follows the adjacency list data model, into an ontology schema + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the adjacency list model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The adjacency list data model for hierarchical classifications proposes to create an entity which holds a list of items with a linking column associated to their parent items. g column associated to their parent items., The generated ontology will be based on th … The generated ontology will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are disambiguated by using an external resource. In the case of that the external resource does not provide any relation between two items, the pattern takes advantage of the use of logical patterns for asserting the relation partOf or subClassOf, as appropriate. tion partOf or subClassOf, as appropriate., 1. Identify the classification scheme item … 1. Identify the classification scheme items which do not have a parent key value, i.e. classification scheme items without parents. 2. For each one of the above identified classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , which are children of cei, by using the parent key values. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Using the external resource identify the semantics of the relation between Cj and Ci, and set up the relation identified. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items without parent cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Using the external resource identify the semantics of the relation between Ci class and the root class, and set up the relation identified. class, and set up the relation identified., … |
| Pattern for re-engineering a classification scheme, which follows the flattened data model, into an ontology schema + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the flattened data model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The flattened data model is a denormalized structure for hierarchy representations. In this case, each hierarchy level is represented on a different column. There are as many columns as levels the classification scheme has. Therefore each row has the complete path from the root to a leaf node. omplete path from the root to a leaf node., The generated ontology will be based on th … The generated ontology will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are disambiguated by using an external resource. In the case of that the external resource does not provide any relation between two items, the pattern takes advantage of the use of logical patterns for asserting the relation partOf or subClassOf. serting the relation partOf or subClassOf., 1. Select all the classification scheme it … 1. Select all the classification scheme items from the first level, using the level column and taking care to avoid duplicity. 2. For each one of the above selected classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , on the next level, which are children of cei, by using the path and level columns. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Using the external resource identify the semantics of the relation between Cj and Ci, and set up the relation identified. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items from the first level cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Using the external resource identify the semantics of the relation between Ci class and the root class, and set up the relation identified. class, and set up the relation identified., … |
| Pattern for re-engineering a classification scheme, which follows the path enumeration data model, into an ontology schema + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the path enumeration model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The path enumeration data model, for classification schemes, takes advantage of that there is one and only one path from the root to every item in the classification. The path enumeration model stores that path as string by concatenating either the edges or the keys of the classification scheme items in the path. e classification scheme items in the path., The generated ontology will be based on th … The generated ontology will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are disambiguated by using an external resource. In the case of that the external resource does not provide any relation between two items, the pattern takes advantage of the use of logical patterns for asserting the relation partOf or subClassOf, as appropriate. tion partOf or subClassOf, as appropriate., 1. Identify the classification scheme item … 1. Identify the classification scheme items whose their path enumeration values have the shortest length, i.e. classification scheme items without parents. 2. For each one of the above identified classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , which are children of cei, by using the path enumeration values. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Using the external resource identify the semantics of the relation between Cj and Ci and set up the relation identified. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items without parent cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Using the external resource identify the semantics of the relation between Ci class and the root class, and set up the relation identified class, and set up the relation identified, … |
| Pattern for re-engineering a classification scheme, which follows the snowflake data model, into an ontology schema + | A non-ontological resource holds a classif … A non-ontological resource holds a classification scheme which follows the snowflake model. A classification scheme is a rooted tree of concepts, in which each concept groups entities by some particular degree of similarity. The semantics of the hierarchical relation between parents and children concepts may vary depending of the context. The snowflake data model is a normalized structure for hierarchy representations. In this case, the classification scheme items are grouped by levels or entities. There are as many groups as levels the classification scheme has. s as levels the classification scheme has., The generated ontology will be based on th … The generated ontology will be based on the taxonomy architectural pattern (AP-TX-01). Each category in the classification scheme is mapped to a class, and the semantics of the relationship between children and parent categories are disambiguated by using an external resource. In the case of that the external resource does not provide any relation between two items, the pattern takes advantage of the use of logical patterns for asserting the relation partOf or subClassOf. serting the relation partOf or subClassOf., 1. Select all the classification scheme it … 1. Select all the classification scheme items from the first level. 2. For each one of the above selected classification scheme items cei: 2.1. Create the corresponding ontology class, Ci class. 2.2. Identify the classification scheme items, cej , on the next level, which are children of cei, by using the parent key values. 2.3. For each one of the above identified classification scheme items cej : 2.3.1. Create the corresponding ontology class, Cj class. 2.3.2. Using the external resource identify the semantics of the relation between Cj and Ci, and set up the relation identified. 2.3.3. Repeat from step 2.2 for cej as a new cei. 3. If there are more than one classification scheme items from the first level cei 3.1. Create an ad-hoc class as the root class of the ontology. 3.2. Using the external resource identify the semantics of the relation between Ci class and the root class, and set up the relation identified. class, and set up the relation identified., … |
| Pattern for re-engineering a term-based thesaurus, which follows the recordbased data model, into an ontology schema + | A non-ontological resource holds a term-ba … A non-ontological resource holds a term-based thesaurus which follows the record-based model. A thesaurus represents the knowledge of a domain with a collection of terms and a limited set of relations between them. The record-based data model is a denormalized structure, uses a record for every term with the information about the term, such as synonyms, broader, narrower and related terms. nyms, broader, narrower and related terms., The generated ontology will be based on th … The generated ontology will be based on the lightweight ontology architectural pattern (AP-LW-01). Each thesaurus term is mapped to a class. For the disambiguation of the semantics of the BT, NT and RT relations among thesaurus terms the pattern relies on an external resource. In the case of that the external resource does not provide any relation between two terms, the pattern takes advantage of the use of logical patterns for asserting the relation partOf, subClassOf or relatedClass. For the UF/USE relations we use the logical pattern proposed by Corcho et al. suggested as best practice in the context of this antipattern: the tendency to declare two classes equivalent when in fact their labels simply express synonym. fact their labels simply express synonym., 1. Identify the records which contain thes … 1. Identify the records which contain thesaurus terms without a broader term. 2. For each one of the above identified thesaurus terms ti: 2.1. Create the corresponding ontology class, Ci class, if it is not created yet. 2.2. Identify the thesaurus terms, tj , which are narrower terms of ti. They are referenced in the same record which contains ti. 2.3. For each one of the above identified thesaurus term tj : 2.3.1. Create the corresponding ontology class, Cj class, if it is not created yet. 2.3.2. Using the external resource identify the semantics of the relation between Cj and Ci, and set up the relation identified. 2.3.3. Repeat from step 2.2 for cj as a new ci 2.4. Identify the thesaurus terms, tr, which are related terms of ti. They are referenced in the same record which contains ti. 2.5. For each one of the above identified thesaurus terms tr: 2.5.1. Create the corresponding ontology class, Cr class, if it is not created yet. 2.5.2. Using the external resource identify the semantics of the relation between Cr and Ci, and set up the relation identified. 2.5.3. Repeat from step 2.4 for cr as a new ci 2.6. Identify the thesaurus terms, tq, which are equivalent terms of ti. They are referenced in the same record which contains ti. 2.7. For each one of the above identified thesaurus terms tq: 2.7.1. Use the logical pattern proposed by Corcho et al. 2.7.2. Repeat from step 2.6 for cq as a new ci. . Repeat from step 2.6 for cq as a new ci., … |
| Pattern for re-engineering a term-based thesaurus, which follows the relationbased data model, into an ontology schema + | A non-ontological resource holds a term-ba … A non-ontological resource holds a term-based thesaurus which follows the relation-based model. A thesaurus represents the knowledge of a domain with a collection of terms and a limited set of relations between them. The relation-based data model is a normalized structure, in which relationship types are not defined as fields in a record, but they are simply data values in a relationship record, thus new relationship types can be introduced with ease. ionship types can be introduced with ease., The generated ontology will be based on th … The generated ontology will be based on the lightweight ontology architectural pattern (AP-LW-01). Each thesaurus term is mapped to a class. For the disambiguation of the semantics of the BT, NT and RT relations among thesaurus terms the pattern relies on an external resource. In the case the external resource does not provide any relation between two terms, the pattern takes advantage of the use of logical patterns for asserting the relation partOf, subClassOf or relatedClass. For the UF/USE relations we use the logical pattern proposed by Corcho et al. suggested as best practice in the context of this antipattern: the tendency to declare two classes equivalent when in fact their labels simply express synonym. fact their labels simply express synonym., 1. Identify the records which contain thes … 1. Identify the records which contain thesaurus terms without a broader term, within the term-term relationship entity. 2. For each one of the above identified thesaurus terms ti: 2.1. Obtain the thesaurus term within the term entity. 2.2. Create the corresponding ontology class, Ci class, if it is not created yet. 2.3. Identify the thesaurus term, tj, which are narrower terms of ti, within the term-term relationship entity. 2.4. For each one of the above identified thesaurus terms tj : 2.4.1. Obtain the thesaurus term within the term entity. 2.4.2. Create the corresponding ontology class, Cj class, if it is not created yet. 2.4.3. Using the external resource identify the semantics of the relation between Cj and Ci, and set up the relation identified. 2.4.4. Repeat from step 2.2 for cj as a new ci 2.5. Identify the thesaurus term, tr, which are related terms of ti, within the term-term relationship entity. 2.6. For each one of the above identified thesaurus term tr: 2.6.1. Obtain the thesaurus term within the term entity. 2.6.2. Create the corresponding ontology class, Cr class, if it is not created yet. 2.6.3. Using the external resource identify the semantics of the relation between Cr and Ci, and set up the relation identified. 2.6.4. Repeat from step 2.4 for cr as a new ci 2.7. Identify the thesaurus term, tq, which are equivalent terms of ti, within the term-term relationship entity. 2.8. For each one of the above identified thesaurus term tq: 2.8.1. Use the logical pattern proposed by Corcho et al. 2.8.2. Repeat from step 2.6 for cq as a new ci 2. Repeat from step 2.6 for cq as a new ci, … |
T | |
| Term-based – record-based model – thesaurus to lightweight ontology + | A non-ontological resource holds a term-ba … A non-ontological resource holds a term-based thesaurus which follows the record-based model. A thesaurus represents the knowledge of a domain with a collection of terms and a limited set of relations between them. The record-based data model is a denormalized structure, uses a record for every term with the information about the term, such as synonyms, broader, narrower and related terms. nyms, broader, narrower and related terms., The generated ontology will be based on th … The generated ontology will be based on the lightweight ontology architectural pattern (AP-LW-01). Each thesaurus term is mapped to a class. A subClassOf relation is defined between the new classes for the BT/NT relation. A relatedClass relation is defined between the new classes for the RT relation. For the UF/USE relations the SynonymOrEquivalence (SOE) pattern is applied. nymOrEquivalence (SOE) pattern is applied., 1. Identify the records which contain thes … 1. Identify the records which contain thesaurus terms without a broader term. 2. For each one of the above identified thesaurus terms ti: 2.1. Create the corresponding ontology class, Ci class, if it is not created yet. 2.2. Identify the thesaurus term, tj , which are narrower terms of ti. They are referenced in the same record which contains ti. 2.3. For each one of the above identified thesaurus term tj : 2.3.1. Create the corresponding ontology class, Cj class, if it is not created yet. 2.3.2. Set up the subClassOf relation between Cj and Ci 2.3.3. Repeat from step 2.2 for cj as a new ci 2.4. Identify the thesaurus term, tr, which are related terms of ti. They are referenced in the same record which contains ti. 2.5. For each one of the above identified thesaurus term tr: 2.5.1. Create the corresponding ontology class, Cr class, if it is not created yet. 2.5.2. Set up the relatedClass relation between Cr and Ci 2.5.3. Repeat from step 2.4 for cr as a new ci 2.6. Identify the thesaurus term, tq, which are equivalent terms of ti. They are referenced in the same record which contains ti. 2.7. For each one of the above identified thesaurus term tq: 2.7.1. Apply the SynonymOrEquivalence (SOE) pattern. ly the SynonymOrEquivalence (SOE) pattern., … |
X | |
| Xsd:sequence embedding + | *For a description of XSD see: http://en.w … *For a description of XSD see: http://en.wikipedia.org/wiki/XML_Schema_(W3C) The pattern covers the cases where an xsd:element is embedded into an xsd:sequence, which is in its turn embedded by an xsd:element. *The graphical representation only illustrates the XSD case. *The DTD case is described in the example section. case is described in the example section., The ontology comprising the pattern representing the relevant XSD or DTD fragment., The re-engineering process involves a numb … The re-engineering process involves a number of steps: *The creation of embedding class and embedded class(es) *The creation of an instance of the hasPart object property from the DOLCE Ultra Light ontology (http://www.ontologydesignpatterns.org/ont/dul/DUL.owl) with embedding class as domain and embedded class(es) as range. as domain and embedded class(es) as range., … |
