On 05/16/2012 11:14 AM, Scott Henninger wrote:
On 5/16/12 12:59 PM, Daniel Elenius wrote:
On 05/16/2012 10:47 AM, Scott Henninger wrote:
On 5/16/12 11:47 AM, Daniel Elenius wrote:
That is incorrect. The semantics of the two restrictions taken
together is that the property values have to be in the intersection
of V1 and V2.
It is not inconsistent unless you also say that V1 and V2 are
disjoint, i.e. the intersection is empty.
I guess it can be seen that way. Keep in mind that the choices for
filling property values is the contrapositive of the actual OWL
inference, which can be stated as:
T(?x, owl:allValuesFrom, ?y)
T(?x, owl:onProperty, ?p)
T(?u, rdf:type, ?x)
T(?u, ?p, ?v)
==> T(?v, rdf:type, ?y)
In that case, multiple type statements will be created - as you
stated, an intersection. So I suppose one could conclude, as you do
that a form filler should display both classes, but that's not quite
right either. It would be most correct to display only the
instances in the union of all the owl:allValuesFrom restrictions for
the property.
And this gets us to the real purpose of Composer's "Add existing..."
feature. It's really to provide a quick indication of what may be
valid slot fillers. We don't attempt to do full inferences, and
that would probably be more confusing to users than not. In this
case, choosing one of the classes is reasonable, as all of the
instances meeting your criteria will be present (and is no more or
less correct than showing all classes for th eproperty
restrictions). Note that one can always click on the 'Show all
types' box if the indicator doesn't display the class you want.
We can think some about some feature enhancements to fill the slots
with the logical consequences of the property restrictions. Note
that performance then becomes an issue. If V1 and V2 had, say 100k
instances each, it could take a minute or two between the time
someone chooses "Add existing..." and the list appears. In the
meantime, autocomplete is also an extremely useful feature.
I am not expecting real reasoning to display appropriate property
values, just slightly better heuristics. Note that TBC arbitrarily
chooses one of the two classes V1 and V2. That doesn't seem right
somehow. Interestingly, Protege 3.5 has the same behavior. It seems
to me that it would be best to show these "shortcuts" to as many
"potentially interesting" classes as possible.
As stated before, displaying one is no more or less correct than
displaying both.
Yes, I agree with this, there is no "correct" thing to do here, just
more or less useful options to help the user. Arbitrarily showing one of
the two classes (V1, V2) seems like a strange choice. I suppose this is
a somewhat unusual corner case though.
In fact, when displaying "both" (in reality there can be n such
restrictions), the chances of choosing an instance that does not meet
the criteria increases. The correct slot filler is instances that
intersect with all owl:allValuesFrom restrictions on that property.
So executing the logical inference would be necessary.
Also keep in mind that an inference engine will create all of the type
triples to make the model consistent. So if you had the restrictions
mentioned above, and the data:
:c_inst1 a :C .
:c_inst1 :prop :someVal .
:someVal a owl:Thing .
...a OWL reasoner will add {:someVal a :V1 . :someVal a :V2}, and the
data will be consistent with the model.
I am aware of this.
-- Scott
While I'm at it, I think I found another bug:
I tried doing allValuesFrom (V1 or V2) just to see if TBC does the
"right" thing, i.e. lets me choose from both classes.
When I use the "create restriction" dialog, select my property,
select allValuesFrom, and put "V1 or V2" as the filler, what I get is:
(prop only V1) or V2
I should get:
prop only (V1 or V2)
When I change it to the correct version manually, TBC does do the
right thing.
Try filling in with "(V1 or V2)". Yes manually editing is another
way to accomplish this.
Ok, but it's confusing that I should have to do that -- "V1 or V2"
*is* the filler, and the parentheses should be added automatically.
Another issue: When I use the first version of the restriction, the
widget for "prop" does not show up on my instance. It might be
helpful in some cases if the prop widget showed up in this case,
even though we don't know that the instance has type "prop only V1"
(because of the disjunction).
By "first version" do you mean '(prop only V1) or V2'? I suppose it
should and it could be another enhancement request.
Yes.
-- Scott
On 05/16/2012 09:06 AM, Scott Henninger wrote:
Daniel; Notice you have created a logical inconsistency here. The
semantics of owl:allValuesFrom is that if a value exists for the
property,then the value can only come from the specified class.
So when you define ":prop only :V1" in the subclass of :C, then
all instances that have a :prop property should be an instance of :V1.
If you then add ":prop only :V2", then you have defined a
contradictory definition - :prop can only be of type V1 and :prop
can only be of type V2.
Composer therefore chooses one of these arbitrarily. Of course,
you can always fill in any value via 'Add empty row" -
autocomplete works nicely.
What you may be looking for is that a :prop in an instance of C
can be filled with a value from either :V1 or :V2. In that case
use the logical OR. I.e., in Manchester syntax:
:prop only (:V1 or :V2)
HTH
-- Scott
On Wednesday, May 16, 2012 10:44:22 AM UTC-5, Daniel Elenius wrote:
I think there is a bug in the "class choosers" for
creating/adding
property values:
Create three top-level classes, C, V1, and V2.
Create a property prop.
On C, add the restriction "prop only V1".
On C, add the restriction "prop only V2".
Create an instance of C.
Select "create and add" on the widget for "prop" on the new
instance.
You only get to choose "V1". You should get "V1" and "V2"
both. Right?
Ok, semantically the property values have to be instances of
V1, but
they may not be asserted that way. It would be very helpful if
you could
browse all the classes in all the inherited restrictions.
Regards,
Daniel
--
You received this message because you are subscribed to the Google
Group "TopBraid Suite Users", the topics of which include
Enterprise Vocabulary Network (EVN), 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
Enterprise Vocabulary Network (EVN), 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 Enterprise
Vocabulary Network (EVN), 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 Enterprise
Vocabulary Network (EVN), 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 Enterprise
Vocabulary Network (EVN), 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 Enterprise Vocabulary
Network (EVN), 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
