Re: [topbraid-users] Re: Owlrl in SPARQL

[Scott Henninger]

<<My point is that this restriction can be used to attach a property with a value directly to a class. For example Orange hasPrice .25. (Scott's response)>> At no point did I say this.  The restriction applies to all members of the class - and the class is the unnamed class that the restriction defines.  This is just a complication of the way OWL represents the data in RDF - logically you define a restriction on either an equivalent class or a subclass.  Then the rules use RDFS subsumption or OWL equivalence to determine membership in the named class. Looking at it a different way, an equivalent class restrictions names the restriction.  I.e. the unnamed class defined by the restriction has exactly the same members as the named class. Please do try this out in the SPARQL view.  I think it will clarify a lot for you. -- Scott On 8/26/11 9:11 AM, Leonard Jacuzzo wrote: Irene (from Italy) You are correct it is a restriction.   My point is that this restriction can be used to attach a property with a value directly to a class. For example Orange hasPrice .25. (Scott's response)   Alternatively one could assert that a class is equivalent to (or a subclass of) a class that is the restriction on the propert hasPrice to the value 25 cents. (Irene's response)   The rules that I am wondering about seem to apply to the first case. Since the rules do not mention restrictions or subclass/equivalent classes.   However, in the second case the same triples from the WHERE clause would be present as well. So the rule should have the same result with the exception that the individual would be classified as a instance of the restriction class (not the class itself e.g. Orange) and the subclass information would be parsed with a rule for subclasses. (given the assertion of subclass or equivalent class)   I think that this is the correct way to understand those rules.   What I find unpalatable about the rule is that if the model is constructed like the first case, with (restricted) properties attached to classes directly, the rule would not be truth preserving. (that is why the first case is an anti-pattern) The second rule: # cls-hv2 CONSTRUCT {     ?u a ?x . } WHERE {     ?x owl:hasValue ?y .     ?x owl:onProperty ?p .     ?u ?p ?y . }   Would classify a lemon as being an orange when the two had the same value for the property of hasPrice.   Maybe I am completely confused. If so, I am eager to be educated. Best wishes, Leonard On Fri, Aug 26, 2011 at 9:01 AM, Irene Celino <irene.cel...@gmail.com> wrote: I should check OWL specification, but I believe that whenever you say that something is the subject of owl:hasValue or of owl:onProperty, you are automatically saying that that something is an owl:Restriction. If I'm not wrong, then in the rule ?x is a restriction (or, if you prefer, it is equivalent to a restriction). 2011/8/26 Leonard Jacuzzo <jacu...@gmail.com>: > Thanks Irene (From Italy), > > But that does not address my point. There is no menition of equivalence or > subclass in the rule. The rule applies, without these statements. > > That is the confusion, Scott asserts that even without the equivalence > statement, if the class orange is asserted to have the price of 25 cents and > if a lime is priced at 25 cents, the lime is classified as an orange, > according to the second rule. > > Irene (from TQ) seems to be saying something different. Her response > requires that there is a statement of equivalence or subclass. This is > absent from Scott's response. > > So I am left wondering which answer is correct, and If Irene (TQ) is > correct, then I am wondering why the rule does not have a statement that x > is a restriction and that the class in question is an equivalent class or a > subclass. > > I hope that makes my question more clear. > Thanks for pitching in. > LFJ > > On Fri, Aug 26, 2011 at 8:42 AM, Irene Celino <irene.cel...@gmail.com> > wrote: >> >> Sorry for jumping in, but I think the confusion comes from the example >> you chose. >> >> Let's say that we define CheapItem as *equivalent* to a restriction on >> property hasPrice with value .25. >> The second rule says that, if you have an orange (= an instance of the >> class Orange) that costs .25, you can infer that it is also instance >> of the class CheapItem. >> If you also have a lime (= an instance of the class Lime) that costs >> .25, it also can be inferred to be instance of CheapItem. >> >> What my homonym at TopQuadrant said is that you can also say that all >> oranges cost .25, by defining the class Orange to be *subclass* of a >> restriction on property hasPrice with value .25. (In this case, the >> first rule says that, if you have an orange (= an instance of the >> class Orange), it must cost .25.) >> But, if you have a lime that costs .25, you *cannot* infer that it is >> also instance of the class Orange, because the subclass definition (in >> place of the equivalence definition) implies that it is possible that >> other things have price .25 without the need of being an orange. >> >> I hope this helps in clarifying the meaning of the two rules. >> Cheers, >> Irene (from Italy) >> >> 2011/8/26 Leonard Jacuzzo <jacu...@gmail.com>: >> > Thanks Irene, >> > >> > But your respons only covers the first rule with the typo in it. Scott >> > asserted that the second rule is such that every individual that has the >> > given property, in our case haveing a price of 25 cents would be a >> > member of >> > the class with that property. So a lime would be an orange if the lime >> > cost >> > 25 cents. His response did not mention equivalence. >> > So I am confused. >> > >> > Also, you are correct. The Sparql rules do mirror the W3C specs. But >> > that >> > does not answer my question as to why there is no assertion that x is a >> > restriction, given your interpretation of that rule. >> > >> > There is still a disconnect between these responses. >> > Best, >> > >> > LFJ >> > >> > On Fri, Aug 26, 2011 at 1:39 AM, Irene Polikoff <ir...@topquadrant.com> >> > wrote: >> >> >> >> Leonard, >> >> >> >> >> >> >> >> ?u ?p ?v will in some cases cause the rule to fail. You should remove >> >> it >> >> from the profile and try again. >> >> >> >> >> >> >> >> < Scott seems to assert that this rule applies when the value >> >> restriction >> >> on the property applies to a class. And it is possible to assign such a >> >> value in TBC. Hence, according to the rule if an object has a price of >> >> 25 >> >> cents, then it is an Orange. > >> >> >> >> >> >> >> >> I don’t  believe there is any disagreement between Scott and I. He, for >> >> example, said: >> >> >> >> >> >> >> >> “So given a [:hasPrice value ".25"^^xsd:float] restriction >> >> >> >> on :Orange, the triple {?u :hasPrice ".25"^^xsd:float} is inferred for >> >> all members of Orange.  “ >> >> >> >> >> >> >> >> What he meant by “restriction on :Orange” is that :Orange is either a >> >> subclass or equivalent class of a has value restriction. It is just a >> >> short >> >> way of speaking. >> >> >> >> >> >> >> >> < But then why doesn't the rule have a triple that asserts that x is a >> >> restriction: ?x a owl: Restriction?> >> >> >> >> >> >> >> >> According to OWL RL spec cls-hv1 is defined as >> >> >> >> >> >> >> >> IF >> >> >> >> >> >> >> >> T(?x, owl:hasValue, ?y) >> >> T(?x, owl:onProperty, ?p) >> >> T(?u, rdf:type, ?x) >> >> >> >> >> >> >> >> THEN >> >> >> >> >> >> >> >> T(?u, ?p, ?y) >> >> >> >> >> >> >> >> cls-hv2 is defined as >> >> >> >> >> >> >> >> IF >> >> >> >> >> >> >> >> T(?x, owl:hasValue, ?y) >> >> T(?x, owl:onProperty, ?p) >> >> T(?u, ?p, ?y) >> >> >> >> >> >> >> >> THEN >> >> >> >> >> >> >> >> T(?u, rdf:type, ?x) >> >> >> >> >> >> >> >> >> >> >> >> Irene >> >> >> >> From: topbraid-users@googlegroups.com >> >> [mailto:topbraid-users@googlegroups.com] On Behalf Of Leonard Jacuzzo >> >> Sent: Thursday, August 25, 2011 10:36 PM >> >> >> >> To: topbraid-users@googlegroups.com >> >> Subject: Re: [topbraid-users] Re: Owlrl in SPARQL >> >> >> >> >> >> >> >> Thanks Irene, >> >> >> >> >> >> >> >> You and Scott seem to have contrasting interpretations of that rule. >> >> >> >> >> >> >> >> Scott seems to assert that this rule applies when the value restriction >> >> on >> >> the property applies to a class. And it is possible to assign such a >> >> value >> >> in TBC. Hence, according to the rule if an object has a price of 25 >> >> cents, >> >> then it is an Orange. >> >> >> >> >> >> >> >> This is indeed strange. So I am eager to believe your interpretation. >> >> >> >> >> >> >> >> But then why doesn't the rule have a triple that asserts that x is a >> >> restriction: ?x a owl: Restriction? If the rule had that clause, it >> >> would >> >> rule out the Scott's take on things. >> >> >> >> >> >> >> >> Anway, I attempted to use the RL profile in a spin file and it did not >> >> classify. Was this because the imported graph was not an official RL >> >> profile? >> >> >> >> >> >> >> >> Thanks again, >> >> >> >> LFJ >> >> >> >> Ps. is the extra triple I pointed out simply noise? or will it cause >> >> the >> >> rule to fail? >> >> >> >> On Thu, Aug 25, 2011 at 9:42 PM, Irene Polikoff <ir...@topquadrant.com> >> >> wrote: >> >> >> >> If the model says that Orange is equivalent class to the anonymous >> >> class >> >> representing all things with the price of .25 and you have a lime that >> >> costs >> >> .25, you will get a conclusion that this lime is an orange. And, if you >> >> have >> >> a statement that these classes are distinct from each other, yes your >> >> model >> >> will be inconsistent. >> >> >> >> >> >> >> >> But this is a problem with the model, not a problem with the >> >> inferences. >> >> If you don’t want this to happen, you can say (as you have suggested) >> >> that >> >> Orange is  a subclass of the anonymous class representing all things >> >> with >> >> the price of .25. You will not get a classification inference then. >> >> >> >> >> >> >> >> < Also, the practice of attaching a property and a value restriction to >> >> a >> >> class might make sense from an OO perspective, but it seems incorrect >> >> from a >> >> modeling perspective. In fact, this is listed among the "Anti- >> >> patterns" in >> >> Dean's book.> >> >> >> >> >> >> >> >> I am not sure what you are talking about. >> >> >> >> >> >> >> >> <How would a rule look that produces the fact that an individual >> >> orange(u) >> >> hasPrice 25 cents?.> >> >> >> >> >> >> >> >> # cls-hv1 >> >> CONSTRUCT { >> >> ?u ?p ?y .} >> >> >> >> WHERE { >> >>     ?x owl:hasValue ?y . >> >>     ?x owl:onProperty ?p . >> >>     ?u a ?x . >> >> } >> >> >> >> ?x is a restriction (anonymous class), not :Orange >> >> >> >> >> >> >> >> The inference that ?u a ?x if :Orange rdfs:subClassOf :?x and ?u a >> >> :Orange >> >> comes from a different rule. >> >> >> >> >> >> >> >> ?u ?p ?v triple was indeed an unnecessary noise. Thanks for pointing it >> >> out. >> >> >> >> >> >> >> >> Irene >> >> >> >> >> >> >> >> >> >> >> >> From: topbraid-users@googlegroups.com >> >> [mailto:topbraid-users@googlegroups.com] On Behalf Of Leonard Jacuzzo >> >> Sent: Thursday, August 25, 2011 7:00 PM >> >> To: topbraid-users@googlegroups.com >> >> Subject: Re: [topbraid-users] Re: Owlrl in SPARQL >> >> >> >> >> >> >> >> Thanks Scott, >> >> >> >> >> >> >> >> But it does not seem reasonable to assert that a lime is an orange >> >> simply >> >> because it has the same price as an orange. >> >> >> >> What would happen is the model contains 'Lime is distinct from Orange". >> >> This would create an inconsistency...no? >> >> >> >> >> >> >> >> Also, the practice of attaching a property and a value restriction to a >> >> class might make sense from an OO perspective, but it seems incorrect >> >> from a >> >> modeling perspective. In fact, this is listed among the "Anti- >> >> patterns" in >> >> Dean's book. >> >> >> >> >> >> >> >> As another question regarding rules. >> >> >> >> >> >> >> >>  Let's say that I avoid this OO pattern and instead define Orange as a >> >> sublcass of a restriction on the property hasPrice to the value 25 >> >> cents. >> >> (because that is better and true and would not result in anything >> >> having the >> >> same price as an orange being classified as an orange).... >> >> >> >> >> >> >> >> How would a rule look that produces the fact that an individual >> >> orange(u) >> >> hasPrice 25 cents?. >> >> >> >> So what I would have something like >> >> >> >> >> >> >> >> Orange rdfs:subClassOf owl:restriction >> >> >> >> owl:onProperty 'hasPrice' >> >> >> >> owl: hasValue "..25" xsdfloat. >> >> >> >> And >> >> >> >> OrangeB rdf:type Orange. >> >> >> >> >> >> >> >> How do I go from there to >> >> >> >> >> >> >> >> OrangeB hasPrice value '.25' xsdfloat. >> >> >> >> >> >> >> >> Sorry for the sloppy fake code..I am a neophyte. >> >> >> >> Thanks again for your help. I have learned a great deal. >> >> >> >> >> >> >> >> Best, >> >> >> >> LFJ >> >> >> >> >> >> >> >> >> >> >> >> So this rule is not truth preserving...in itself. It would only be >> >> truth >> >> preserving with the appropriate "distinct' values. >> >> >> >> On Thu, Aug 25, 2011 at 6:24 PM, Scott Henninger >> >> <shennin...@topquadrant.com> wrote: >> >> >> >> Hello Leonard;  Yes I do believe this is a typo in the rule set.  We >> >> will look into this some more and get it fixed for the 3.6 release. >> >> >> >> The two rules, cls-hv1 and cls-hv2, are converses of each other.  cls- >> >> hv1 covers the case where if a class defines a hasValue restriction >> >> property, then all members of the class must have that property >> >> value.  The rule infers this, in typical OWA fashion, making the model >> >> consistent.  So given a [:hasPrice value ".25"^^xsd:float] restriction >> >> on :Orange, the triple {?u :hasPrice ".25"^^xsd:float} is inferred for >> >> all members of Orange.  Note that members of :Orange can also have >> >> other :hasPrice values - e.g. {?u :hasPrice ".50"^^xsd:float} - and >> >> that is consistent with the model. >> >> >> >> The cls-hv2 covers the case that if a resource meets the hasValue >> >> criteria, then it is a member of the class.  So let's say we have an >> >> instance with the triple {:alime a :Lime ; :hasPrice ". >> >> 25"^^xsd:float}, since the value of :hasPrice is .25, it meets the >> >> criteria of :Orange membership and therefore the rule infers {:alime >> >> a :Orange}.  The tricky part to understand in this query is that ?u >> >> refers to any resource.  In our example the graph pattern is matched >> >> as: >> >>   WHERE >> >>   {   ?x owl:hasValue ?y .  ## ?x bound to bnode representing the >> >> restriction, ?y bound to ".25" >> >>       ?x owl:onProperty ?p . ## ?p bound to :hasPrice >> >>       ?u ?p ?y .  ## ?u bound to : alime >> >>   } >> >> >> >> Try this in your SPARQL view by applying the above to a model that has >> >> some hasValue restrictions.  I'd suggest using 'SELECT *' so you can >> >> follow the variable mappings. >> >> >> >> <<BTW: what does it mean to assert that a class X hasValue y on >> >> property P? >> >> The class Orange does not have a price, only individual oranges have a >> >> price.>> >> >> >> >> If you are familiar with OO programming, this is akin to a class >> >> variable.  hasValue restrictions are defined on the class and applies >> >> "automatically" to all instances.  This is basically what cls-hv1 >> >> does.  cls-hv2 allows you to also infer that anything with the >> >> property-value pair is a member of the class. >> >> >> >> -- Scott >> >> >> >> On Aug 25, 3:39 pm, Leonard Jacuzzo <jacu...@gmail.com> wrote: >> >> > Hello list, >> >> > >> >> > Thank you for all of the help that you have been to me in >> >> > understanding >> >> > how >> >> > to use SPARQL for rule creation. >> >> > >> >> > I have a few questions. >> >> > >> >> >> >> > I was looking over the specification of OWL-RL >> >> > athttp://topbraid.org/spin/owlrl-all.html >> >> >> >> > >> >> > The rule cls hv1 has a typo in it. The last triple in the WHERE >> >> > clause >> >> > has >> >> > not function in the rule and is not part of the W3C specification. >> >> > That >> >> > is >> >> > "?u?p ?v should be removed. Here is the rule as it stands. >> >> > # cls-hv1 >> >> > CONSTRUCT { >> >> >     ?u ?p ?y .} >> >> > >> >> > WHERE { >> >> >     ?x owl:hasValue ?y . >> >> >     ?x owl:onProperty ?p . >> >> >     ?u a ?x . >> >> >     ?u ?p ?v . >> >> > >> >> > } >> >> > >> >> > I am also confused by the following rule, which conforms to the W3C, >> >> > but >> >> > makes no sense to me. Can you explain it to me? >> >> > Here is the rule: >> >> > # cls-hv2 >> >> > CONSTRUCT { >> >> >     ?u a ?x .} >> >> > >> >> > WHERE { >> >> >     ?x owl:hasValue ?y . >> >> >     ?x owl:onProperty ?p . >> >> >     ?u ?p ?y . >> >> > >> >> > } >> >> > >> >> > The reason that I am confused is that it seems easy to come up with a >> >> > counter example. E.G. imagine that the class "Orange' hasvalue .25 on >> >> > the >> >> > property "hasPrice" (so oranges are priced at 25 cents) Further >> >> > imagine >> >> > that >> >> > some individual lime(u) hasPrice .25. It does not follow from this >> >> > that >> >> > Lime >> >> > (u) is a lemon. >> >> > >> >> > What am I missing in my understanding of this rule? >> >> > >> >> > BTW: what does it mean to assert that a class X hasValue y on >> >> > property >> >> > P? >> >> > The class Orange does not have a price, only individual oranges have >> >> > a >> >> > price. Should this be a Orange is a subclass of the restriction on >> >> > the >> >> > property "hasPrice" to the value 25 cents? When would a person use >> >> > the >> >> > structure in the WHERE clause? >> >> > >> >> > I have one more question about rules, but I will wait until I think >> >> > some >> >> > more. >> >> > >> >> > Thank you for reading this. Any help will be great, >> >> > LFJ >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> >> Group "TopBraid Suite Users", the topics of which include TopBraid >> >> Composer, >> >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> >> To post to this group, send email to >> >> topbraid-users@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> topbraid-users+unsubscr...@googlegroups.com >> >> 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 >> >> Group "TopBraid Suite Users", the topics of which include TopBraid >> >> Composer, >> >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> >> To post to this group, send email to >> >> topbraid-users@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> topbraid-users+unsubscr...@googlegroups.com >> >> 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 >> >> Group "TopBraid Suite Users", the topics of which include TopBraid >> >> Composer, >> >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> >> To post to this group, send email to >> >> topbraid-users@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> topbraid-users+unsubscr...@googlegroups.com >> >> 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 >> >> Group "TopBraid Suite Users", the topics of which include TopBraid >> >> Composer, >> >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> >> To post to this group, send email to >> >> topbraid-users@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> topbraid-users+unsubscr...@googlegroups.com >> >> 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 >> >> Group "TopBraid Suite Users", the topics of which include TopBraid >> >> Composer, >> >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> >> To post to this group, send email to >> >> topbraid-users@googlegroups.com >> >> To unsubscribe from this group, send email to >> >> topbraid-users+unsubscr...@googlegroups.com >> >> 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 >> > Group "TopBraid Suite Users", the topics of which include TopBraid >> > Composer, >> > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> > To post to this group, send email to >> > topbraid-users@googlegroups.com >> > To unsubscribe from this group, send email to >> > topbraid-users+unsubscr...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/topbraid-users?hl=en >> > >> >> >> >> -- >> >>     " If you understand what you're doing, >>            you're not learning anything. " >> >> -- >> You received this message because you are subscribed to the Google >> Group "TopBraid Suite Users", the topics of which include TopBraid >> Composer, >> TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. >> To post to this group, send email to >> topbraid-users@googlegroups.com >> To unsubscribe from this group, send email to >> topbraid-users+unsubscr...@googlegroups.com >> 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 > Group "TopBraid Suite Users", the topics of which include TopBraid Composer, > TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. > To post to this group, send email to > topbraid-users@googlegroups.com > To unsubscribe from this group, send email to > topbraid-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/topbraid-users?hl=en > --     " If you understand what you're doing,            you're not learning anything. " -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com 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 Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com 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 Group "TopBraid Suite Users", the topics of which include TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en