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