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