Hi Irene, Thx for your information/explanation. Since you say " If, for some unusual reason, you wanted to create restrictions independently from the named classes they are used to define, y" I try to reformulate a bit better, just to better understand (in my reasoning it's not an unuasual reason so I probably don't understand it right....).
Suppose I have A(x) and R(x), A being a named class and R being an anonymous restriction class. I then see three options that could be relevant: 1) A(x) -> R(x) You define the class A and define the restriction R for it and make A a subclass of R. R is a necc. condition for A. 2) A(x) <-> R(x) You define a class A and define again restriction R but now say equivalent class iso subclass. R is a necc. and also sufficient condition for A (in case you know something satisfies R(x) you know it is a member of A(x) so you could automatically classify. So these two ways are the typical constructs I up to now encountered and used. But now the unusual one, in second sight doesnt seem so unusual at all (well to me): 3) R(x) -> A(x) Now we cannot start with a defined class but have to first instantite R(x) after making it visible in the class tree. So we define a restriction class and then say its a subclass of A(x). Now we can only partially/incomplete classify because R(x) is optional for A. (so in my view 2) is just 1) AND 3)....) Is this storysofar still ok? and can indeed reasoners do 3) because they can already do 2, which is in fact 1and3)? Thx again! Michel 2015-04-14 17:41 GMT+02:00 Bohms, H.M. (Michel) <[email protected]<mailto:[email protected]>>: Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locaties/DTM> [cid:[email protected]]<http://www.tno.nl/> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Irene Polikoff Sent: dinsdag 14 april 2015 16:16 To: [email protected]<mailto:[email protected]> Subject: Re: [topbraid-users] sufficient modelling Michel, If I understood you correctly, the answer is “it doesn’t matter, the end result is always the same”. Create a restriction your usual way, then expand it in the class form and ctrl click on the owl:Restriction in the expanded display to navigate to it. You will see that it has an instance (or several instances depending on how many restrictions you have created). These instances are anonymous resources of type owl:Restriction. You can explore them. If, for some unusual reason, you wanted to create restrictions independently from the named classes they are used to define, you could go to Preferences in TBC and adjust them for the Classes tree so that owl:Restriction appears there. Then create instances. Put the appropriate properties in the owl:onProperty widget and appropriate classes or values into owl:hasValue, owl:someValuesFrom or whatever you want to use. Then, go to a named class and drag and drop the appropriate instance into the rdfs:subClassOf or owl:equivalentClass widgets. If you look at the resulting RDF, it will be identical irrespective of how you got there (provided that it is the same type of restriction). <Hwat does it mean to be sufficient but NOT necessary? (potential incomplete classification?)> "Sufficient and necessary" terminology is not part of OWL. It is Protégé specific terminology. In OWL, there are rdfs:subClassOf and owl:equivalentClass connections to some other classes. The meaning ((what could be inferred) based on such relationships to restrictions is defined in the OWL spec. It depends on the type of restriction. For example: If :Class1 is a subclass of a restriction [onproperty hasID, owl:hasValue=14220), then for each :A rdf:type :Class1, you can infer that :A :hasId ‘14220’. But if you have a resource :B of some other or unknown type and :B :hasId ‘14220’, you can’t infer that :B rdf:type :Class1. If :Class1 is an equivalent class of this restriction, then you can make both inferences - :A :hasId ‘14220’ and B rdf:type :Class1. Regards, Irene Polikoff From: "Bohms, H.M. (Michel)" <[email protected]<mailto:[email protected]>> Reply-To: <[email protected]<mailto:[email protected]>> Date: Tuesday, April 14, 2015 at 5:53 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [topbraid-users] sufficient modelling I have a question about modelling “subclassses the other way round”. Typically I model, classes with restrictions being described as subclasses of anonom. classes. Sometimes I do the same with equivelnt classes in case of necc. & sufficient conditions. But, til now, I never modelled only the way back….saying a an. Restriction class as subclass of a named class. (so my LHS of x-> y is now something like [onproperty hasID, owl:hasValue=14220) With that info I could check an instance for this code and derive it is an instance of my named class. Another example: everything having a xHeight is actially an X. (same but now using someValuesFrom iso hasValue) So now my questions: - How do I do this in topbraid (till now it was the other way round, defining a class and then a restriction) - Since equivalence is both ways I guess the way back only also makes sense right? - Hwat does it mean to be sufficient but NOT necessary? (potential incomplete classification?) - How do reasoners deal with this backward Subclassing (do they do it? Is it much harder for them for such complex LHS…?) - Thanks a lot! Michel Dr. ir. H.M. (Michel) Bohms Sr. Research Scientist Structural Reliability T +31 (0)88 866 31 07 M +31 (0)63 038 12 20 E [email protected]<mailto:[email protected]> Location<http://www.tno.nl/locaties/DTM> [cid:[email protected]]<http://www.tno.nl/> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected]<mailto:[email protected]> --- 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]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected]<mailto:[email protected]> --- 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]<mailto:[email protected]>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), Reference Data Manager (RDM), TopBraid Composer, TopBraid Live, TopBraid Insight, SPARQLMotion, SPARQL Web Pages and SPIN. To post to this group, send email to [email protected] --- 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/d/optout.
