There is more than one modeling pattern you can use. Let's consider the following examples:
Approach 1: : DecisionAnalsysisMethod a owl:Class (or it could be a :Method class) :MultiCriteriaDecisionanalsysisMethod a :DecisionAnalsysisMethod :CriterionWeightingMethod a :DecisionAnalsysisMethod :PairwiseComparison a :DecisionAnalsysisMethod :AlternativeScreeningMethod a :DecisionAnalsysisMethod :CriterionWeightingMethod skos:broader :MultiCriteriaDecisionanalsysisMethod :PairwiseComparison skos:broader :CriterionWeightingMethod :AlternativeScreeningMethod skos:broader :MultiCriteriaDecisionanalsysisMethod Pros: . You don't need to worry how far down the tree goes. If someone wants to add another analysis method, they just create one and use skos:broader to hang it in the appropriate place . You can define properties common to most decision analysis methods and use these fields when you describe the instances. Cons: . You don't have an easy way to identify properties unique to, for example, :CriterionWeightingMethod that must be present for things "under it" such as :PairwiseComparison. o The approach to use then is to include all properties in the decision analysis methods class definition and only enter the information if applicable. But, this means that if your situation is such that you want to autoclassify method instances, you could not use standard OWL inferencing to do this. You can still use SPIN to figure out which is a broader of which. This is the approach I would recommend based on what I heard about your requirements. The important point here is that instances (and not only classes) can be organized into hierarchies of their own and any property, not just rdfs:subClassOf can be used to describe hierarchies. Approach 2: :DecisionAnalsysisMethod, :MultiCriteriaDecisionanalsysisMethod, :CriterionWeightingMethod, :PairwiseComparison, :AlternativeScreeningMethod a owl:Class :MultiCriteriaDecisionanalsysisMethod rdfs:subClassOf :DecisionAnalsysisMethod :CriterionWeightingMethod rdfs:subClassOf :MultiCriteriaDecisionanalsysisMethod :PairwiseComparison rdfs:subClassOf :CriterionWeightingMethod :AlternativeScreeningMethod rdfs:subClassOf :MultiCriteriaDecisionanalsysisMethod Pros: . You don't need to worry how far down the tree goes. If someone wants to add another analysis method, they just create one as a class and use subclassOf to hang it in the appropriate place Cons: . You don't have an easy way to associate values with these resources since they are classes o You could use custom annotations, but then how to 'hang' them on the appropriate classes? o If you need to do this, you are forced to go into meta-modeling which is not supported by any OWL inferencers, is not really in the 'spirit' of RDFS/OWL, looks 'unusual' and tends to be complex to understand Approach 3: class:DecisionAnalsysisMethod, class:MultiCriteriaDecisionanalsysisMethod, class:CriterionWeightingMethod, class:PairwiseComparison, class:AlternativeScreeningMethod a owl:Class :MultiCriteriaDecisionanalsysisMethod rdfs:subClassOf :DecisionAnalsysisMethod :CriterionWeightingMethod rdfs:subClassOf :MultiCriteriaDecisionanalsysisMethod :PairwiseComparison rdfs:subClassOf :CriterionWeightingMethod :AlternativeScreeningMethod rdfs:subClassOf :MultiCriteriaDecisionanalsysisMethod instance:MultiCriteriaDecisionanalsysisMethod a class:MultiCriteriaDecisionanalsysisMethod instance:CriterionWeightingMethod a class:CriterionWeightingMethod instance:PairwiseComparison a class:PairwiseComparison and so on Pros: . You don't need to worry how far down the tree goes. If someone wants to add another analysis method, they just create one as a class and use subclassOf to hang it in the appropriate place. They also create an appropriate instance. Owl:hasValue restrictions can be used to maintain the consistent relationship between classes graph and instances graph . You have an easy way to identify properties unique to, for example, :CriterionWeightingMethod. Define them for the appropriate class. Enter the value for the appropriate instance. Cons: . Considerably more complex model, harder to understand and maintain From: [email protected] [mailto:[email protected]] On Behalf Of Li, Naicong Sent: Monday, March 11, 2013 8:36 PM To: [email protected] Subject: [topbraid-users] Modeling best practice question Hi, I have a modeling best practice question, and I hope I can get some answers from the experienced ontology developers at this forum. I apologize if this is the wrong forum to do this - please let me know. I often have to code things that can be treated, from a practical perspective, either class or instance. For example, multi-criteria decision analysis methods. You can say they are all instances of the class MultiCriteriaDecisionanalsysisMethod, but they form a hierarchical structure too: MultiCriteriaDecisionanalsysisMethod CriterionWeightingMethod PairwiseComparison . AlternativeScreeningMethod . MultiAttributeCombinationMethod . . I have been coding all the methods as classes, since even for a method that is the leaf level method for now, some day someone may have developed some sub methods for it (e.g. we had SenstivityAnalysisMethod as a leaf class, which later got expanded to several sub methods such as SpatialSenstivityAnalysisMethod and AspatialSenstivityAnalysisMethod, each of which had their own sub-methods.). In the same time I have been treating them like instances in the sense that I have been using the properties specified on the top method class for all the sub classes - it's like treating the sub classes as the instances of the top class. I did this inside the Composer by simply dragging the properties into the Form view of a method subclass (and specify values for them). But of course I haven't been able to use some of the nicer functions in Composer for instances, such as the Form Layout view. My questions is, is there a way for me to create a method class to which all the methods above are instances? And in the same time keep my method class hierarchy? For example create a method class as a subclass under owl:Class, and add all the method classes above as instances to this new method class? Is this the right way to do it? What's the best practice? Thanks. Naicong ______________________________ Naicong Li, Ph.D. Redlands Institute, University of Redlands 1200 East Colton Avenue, PO Box 3080, Redlands, CA 92373-0999 Email: <mailto:[email protected]> [email protected] Phone: 909-748-8523 -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out. -- -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en --- You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
