Re: [topbraid-users] Re: Multiple allValuesFrom restrictions

[Scott Henninger]

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. 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. 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. -- 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 topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com 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 topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com 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 topbraid-users@googlegroups.com To unsubscribe from this group, send email to topbraid-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en