Line 5: Line 5:
 
{{Architectural OP General Template
 
{{Architectural OP General Template
 
|Name=View Inheritance
 
|Name=View Inheritance
|SubmittedBy=BenedictoRodriguezCastro, Hugh Glaser
+
|SubmittedBy=BenedictoRodriguezCastro, HughGlaser
 
|Author=Benedicto Rodriguez-Castro, Hugh Glaser
 
|Author=Benedicto Rodriguez-Castro, Hugh Glaser
 
}}
 
}}
Line 17: Line 17:
  
 
* ''CiClass_xCjClass_y'', ''Ci_Class_xClass_y'': These classes participate in multiple inheritance relationships combining different refinements from the alternative abstraction criteria classes (''C1Class3_C2Class2'' and ''C1_Class1Class2'' in the Figure above).
 
* ''CiClass_xCjClass_y'', ''Ci_Class_xClass_y'': These classes participate in multiple inheritance relationships combining different refinements from the alternative abstraction criteria classes (''C1Class3_C2Class2'' and ''C1_Class1Class2'' in the Figure above).
}}  
+
}}
 
{{Architectural OP Example Template
 
{{Architectural OP Example Template
|Problem=  
+
|Problem={{Include Image
{{Include Image
+
|ImageName=Fig_avizienis_fault_5a.jpg
+
 
}}
 
}}
Matrix representation of Fault in Avizienis et al. [1] used in the ReSIST KB ontology.
 
 
[1] Avizienis, A., Laprie, J.C., Randell, B., Landwehr, C.: Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing 01(1) (2004) 11--33
 
}}
 
 
 
{{Architectural OP Reference Template}}
 
{{Architectural OP Reference Template}}
  
 
{{Scenarios about me}}
 
{{Scenarios about me}}
 
{{Reviews about me}}
 
{{Reviews about me}}

Revision as of 11:21, 29 August 2009

Warning.gif

Warning!

This is an old revision. Go to current revision

Certified.png
This pattern has been certified.

Related submission, with evaluation history, can be found here

Working.gif Last modified date is: 2009-08-29

Fig view inheritance structure.png

General information

Name View Inheritance
Also known as
Author(s) Benedicto Rodriguez-Castro, Hugh Glaser
Domain (if applicable)
Submitted by BenedictoRodriguezCastro, HughGlaser



Description

Problem description There are ontology domain concepts that are difficult to represent due to the complexities in their definition and the presence of multiple alternative criteria to classify their abstractions.
Solution description Introduce the following types of classes:
  • Criterion_i: These classes represent each one of the alternative abstraction criteria of the TargetDomainConcept (Criterion1, Criterion2, Criterion_i in the Figure above). The list of classes may not be exhaustive or pairwise disjoint.
  • Ci_Class_x: These classes refine each abstraction criteria class (C1_Class1, ..., C2_Class1, ..., Ci_Class_i in the Figure above). The list of classes may not be exhaustive or pairwise disjoint.
  • CiClass_xCjClass_y, Ci_Class_xClass_y: These classes participate in multiple inheritance relationships combining different refinements from the alternative abstraction criteria classes (C1Class3_C2Class2 and C1_Class1Class2 in the Figure above).
Implementation workflow
Reusable component

{{Architectural OP Example Template |Problem=


Pattern reference

Origin
Known use
Reference
Related ODP


Scenarios

Scenarios about View Inheritance

No scenario is added to this Content OP.

Reviews

Reviews about View Inheritance
There is no review about this proposal.
Some subquery has no valid condition.

This revision (revision ID 5640) takes in account the reviews: none

Other info at evaluation tab

The page [[Bootstrap:Footer]] was not found.