Thanks Scott, Now that you have made it an anonymous class the rule makes sense. So I guess I was inadvertently pointing out an error in it's expression. Does this error also happen in the W3C. It seems to me that it does, but I will have to review how they use variables.
I have seen people using values with properties attached to classes. I will look at their code to see how it pans out in OWL. Thanks for clearing this up. The 'a' really makes a difference. It did not seem correct w.r.t. to owl semantics when it was an '?x' Best wishes, Leonard On Fri, Aug 26, 2011 at 4:05 PM, Scott Henninger <[email protected] > wrote: > Leonard; Please refer to the OWL specs. I believe that owl:hasValue is > only valid inside of a restriction. So it can't be applied to a named > class. > > Classes can have properties. In RDF any resource can have properties. If > a class has a non-annotation property, it is generally considered bad > modeling practice, but there can always be exceptions and it is a matter of > preferences and/or massaging your OWL model to get the inferences you want. > > But I don't know how that relates to the discussion. Take a look at the > attached example, which includes the corrected cls-hv1. There are no > property definitions on any classes. The class Orange has a hasValue > restriction: > :Orange > a owl:Class ; > rdfs:subClassOf > [ a owl:Restriction ; > owl:hasValue ".25"^^xsd:float ; > owl:onProperty :hasPrice > ] . > > Run inferences and you will see that: > 1) { :aOrange :hasPrice ".25"^^xsd:float} is inferred via cls-hv1 (use > the light bulb in the Inferences view to see how the inference was > constructed) > 2) { :alime a [:hasPrice value ".25"^^xsd:float]} is inferred via cls-hv2. > Note it is inferred as a member of the unnamed restriction class. > > Move the restriction from rdfs:subClassOf to owl:equivalentClass. Now all > members of the restriction will be the same as members of :Orange. Re-set > inferences and run them again. > > This will also infer that :alime is a member of :Orange. This is > precisely how OWL works w.r.t. hasValue restrictions, with implications from > equivalentClass vs. subClassOf. It is not an artifact of the RL profile or > the SPARQL rules we used to implement the profile. It is a basic OWL 1 > inference, and is absolutely correct w.r.t. OWL semantics. > > -- Scott > > > > On 8/26/11 1:54 PM, Leonard Jacuzzo wrote: > > Thanks Scott! > > Thanks for hanging in there. > Two points. > A. The hasValue rules do not contain the restriction part, so it could be > applied to a named class. > > B. it is possible in TBC to give classes properties such as hasPrice and a > value for hasPrice. Which seems ok from the perpective that classes can have > properties. But I think such modeling is a mistake since it will result in > things like Limes being oranges. Given that RL rule. > > Best wishes, > LFJ > > On Fri, Aug 26, 2011 at 2:47 PM, Scott Henninger < > [email protected]> wrote: > >> <<But it does not seem reasonable to assert that a lime is an orange >> simply because it has the same price as an orange. >> >> >> >> No, it's entirely consistent with the model. I purposefully created the >> example to show that the logical relationships created by the restriction >> are what matters, not the name. >> >> <<What would happen is the model contains 'Lime is distinct from Orange". >> This would create an inconsistency...no?>> >> >> Yes, if you had the assertion {:Lime owl:disjointClass :Orange} then there >> would be an inconsistency since :alime is a member of both. >> >> You can also specify a cardinality restriction that there can only be one >> price. This doesn't result in an inconsistency, but a SPIN constraint can >> easily be created that checks for multiple prices. >> >> <<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 think I understand the misunderstanding. The anti-pattern, I'm >> guessing, is the expectation that a property defined on a class is >> automatically copied to (sometimes incorrectly called "inherited by") the >> instance. This is an entirely different topic from what I stated - please >> note the careful placement of the term "akin" in my statement below. >> >> First, let's be clear about the semantics of hasValue. A hasValue >> restriction on a property means that in a consistent model all members of >> the class (yes, the unnamed restriction class) have that property-value >> (e.g. :hasPrice ".25"^^xsd:float). This is often referred to as >> "entailment" - the restriction entails that all members of the class have >> this property-value pair. If an instance does not, then the model is >> inconsistent, and the reasoner will add the property-value pair to the >> instance to make it consistent. >> >> The semantics of hasValue also states that if any resource matches the >> property-value pair, then it is a member of the class. This is where the >> fact that "the class" is the restriction class becomes important. The >> inference occurs for the restriction class always. But if the restriction >> is a subclass of the named class, then we can't infer that the instance is a >> member of that class - members of the class may not be members of the >> subclass. If the restriction is on an equivalent class property, then we >> can make the inference on the named class since the members of the unnamed >> restriction class and the named class are the same. >> >> I believe the OWL spec does not allow for named classes for defining the >> restrictions. >> >> -- Scott >> >> On 8/25/11 5:59 PM, Leonard Jacuzzo wrote: >> >> 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 < >> [email protected]> 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 <[email protected]> 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 >>> [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 >> 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 >> [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 >> 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 >> [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 > 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 > [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 > 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 > [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 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 [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
