Hi Irene, when experimenting.... It seemd not possible to instantiate a Restriction (seperate from a class). indicating the owl:onProperty went fine nut then trying to give it a string value does not work (text stays red). any suggestions?
(I also tried to define other way round for a class but then when deleting the class the restriction is also deleted so that does not work...) thx michel what I did: - define Class Put - define a datattype property code with range string - defined a (anonymous) restriction with owl:onProperty code (went fine) - then tried to put say : 111" into owl:hasValue and THAT did not work... if that worked I would try to make Put a sunclass of that restriction and define an individual with coe "111" and then see if after reasoning I have an individual of Put inferred. (that was the idea) Op woensdag 15 april 2015 14:52:07 UTC+2 schreef Irene Polikoff: > > <and can indeed reasoners do 3) because they can already do 2, which is in > fact 1and3)?> > > You should experiment and see what happens. 3 alone should give you an > inference :B rdf:type :Class1 in my example. > > Irene > > > From: "Bohms, H.M. (Michel)" <[email protected] <javascript:>> > Reply-To: <[email protected] <javascript:>> > Date: Wednesday, April 15, 2015 at 3:19 AM > To: "[email protected] <javascript:>" < > [email protected] <javascript:>> > Cc: "[email protected] <javascript:>" <[email protected] > <javascript:>> > Subject: FW: FW: [topbraid-users] sufficient modelling > > > > 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] > <javascript:>>: > > > > > > > > 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] <javascript:> > > Location <http://www.tno.nl/locaties/DTM> > > > > <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] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Irene Polikoff > *Sent:* dinsdag 14 april 2015 16:16 > *To:* [email protected] <javascript:> > *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] <javascript:>> > *Reply-To: *<[email protected] <javascript:>> > *Date: *Tuesday, April 14, 2015 at 5:53 AM > *To: *"[email protected] <javascript:>" < > [email protected] <javascript:>> > *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] <javascript:> > > Location <http://www.tno.nl/locaties/DTM> > > > > <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] > <javascript:> > --- > 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] <javascript:>. > 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] > <javascript:> > --- > 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] <javascript:>. > 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] > <javascript:> > --- > 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] <javascript:>. > 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.
