<<Ps. is the extra triple I
pointed out simply noise? or will it cause the rule to fail? >>
It will cause the rule to fail. I'd suggest creating a new SPIN
rule with the corrected rule and add to the owl:Thing class.
(This is less dangerous than modifying the rule set itself, as
Irene suggested.) Then the inference will occur correctly. For
the record, the corrected rule is:
# cls-hv1
CONSTRUCT {
?u ?p ?y .
}
WHERE {
?x owl:hasValue ?y .
?x owl:onProperty ?p .
?u a ?x .
}
-- Scott
On 8/25/11 9:35 PM, Leonard Jacuzzo wrote:
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 <[email protected]>
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
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.
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.
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
|
