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.
>
>
> 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
|
