Thanks Holger, You are correct, but I have been ferrying this string through several .txt files and must have been confused when I pasted.
Luckily Scott understood what I was attempting to express. He seems very intelligent. Also, I was not complaining about infinite loops. Please read what I write more carefully, Best wishes, Leonard On Tue, Jul 19, 2011 at 9:52 PM, Holger Knublauch <[email protected]>wrote: > > On Jul 20, 2011, at 8:34 AM, Leonard Jacuzzo wrote: > > Scott, > You are like Santa Claus everyday! Thanks. > > > There was also a typo in your query - once you sp > > eak about ?var1 and then ?Var1 - uppercase makes a difference in SPARQL. > > > My use of 'implied by'. Was not intended to suggest that SPIN works from > implication. That might be the key feature of SPIN. If I know it is implied, > I can get the machine to get it for me. Since the models are finite, and if > SPIN is sound and complete (which I think I can prove that it > is), decidablity won't be a problem, and hopefully not scalability either. > BTW: I have seen 'indecidable' to mean "produces an infinite loop". > > > I am pretty sure you can run into an infinite loop, e.g. just have a rule > that produces a new blank node and another rule that queries for those blank > nodes. Or have a SPIN function that calls another SPIN function recursively > that never finishes. So in the worst case it will be possible to construct > cases where SPIN/SPARQL is too expressive. However, Java also allows you to > make infinite loops, and I don't think anyone will argue that Java is > useful. The responsible is shifted towards the rule developer, while > languages like OWL try to "protect" users from possible logic errors by > limiting the expressivity. See also > > http://composing-the-semantic-web.blogspot.com/2010/04/where-owl-fails.html > > Holger > > > I use 'decidable' in the strict sense to mean "one cannot determine of a > given well-formed formula whether it is or is not an implication of a given > axiom set" > > With SPIN I would already know that it is implied. So that would not be an > issue. > > But I digress. Thanks again. > > > Best wishes, > Leonard > P.S. When I write an abstract on the logicallproperties of SPIN, I will > send it to you off list. Maybe we can collaborate. > > On Tue, Jul 19, 2011 at 6:26 PM, Scott Henninger < > [email protected]> wrote: > >> Hello Leonard; The query doesn't create any triples because there >> isn't a value bound for ?restriction. To get a new restriction, you >> will need to create a URI that defines the restriction. This can be a >> named URI, through smf:buildURI(), etc., but there are good reasons to >> stick with the OWL standard and not name it (i.e. use a bnode). Try >> the following query in the SPARQL view for a class with a matching >> restriction: >> >> CONSTRUCT {?this rdfs:subClassOf _:b0 . >> _:b0 rdf:type owl:Restriction . >> _:b0 owl:onProperty :isPartOf . >> _:b0 owl:someValuesFrom ?Var1 . } >> WHERE { >> ?this rdfs:subClassOf ?restriction1 . >> ?restriction1 rdf:type owl:Restriction . >> ?restriction1 owl:onProperty :hasPart . >> ?restriction1 owl:someValuesFrom ?Var1 . >> } >> >> Then you can assert or infer the graph returned by CONSTRUCT and you >> will see how it works in Composer's UI. A suggestion is to use the >> graph or source view to explore how the restrictions work. These, and >> exploring with SPARQL queries (e.g. {?restriction1 ?p ?o}) are >> valuable tools for designing any SPARQL query, including SPIN rules, >> functions, templates, etc. >> >> From the above, you can create a SPIN template that passes in a >> variable for ?Var1 in the above CONSTRUCT graph pattern. That would >> allow you to create the restriction on some class different than the >> original restriction. >> >> Also, in terms of "the constructed triple is implied by the model", >> keep in mind that SPARQL is a graph language. Unless otherwise >> specified, no implications (entailments) are assumed or computed when >> executing a query. >> >> -- Scott >> >> On Jul 19, 3:42 pm, Leonard Jacuzzo <[email protected]> wrote: >> > Hi Scott, >> > I have attempted to use the following rule in TBC-Me 3.5.1. But it did >> not >> > fire. I also tried it as a SPARQL query and it did not do anything. I >> > clicked the tab and it blink and gave me a blank result. >> > >> > The syntax is correct and the constructed triple is implied by the >> model. >> > (unless maybe the syntax is not correct) >> > Do you have any idea why this shouldn't work? >> > See below, >> > Best wishes, >> > Leonard >> > >> > CONSTRUCT {?var1 rdfs:subClassOf ?restriction . >> > ?restriction rdf:type owl:Restriction . >> > ?restriction owl:onProperty :isPartOf . >> > ?restriction owl:someValuesFrom ?Var . } >> > >> > WHERE { >> > >> > ?VAR rdfs:subClassOf ?restriction1 . >> > ?restriction1 rdf:type owl:Restriction . >> > ?restriction1 owl:onProperty :hasPart . >> > ?restriction1 owl:someValuesFrom ?Var1 . >> > >> > } >> > On Sat, Jul 16, 2011 at 3:02 PM, Leonard Jacuzzo <[email protected]> >> wrote: >> > > Hi Scott, >> > >> > > My reason for wanting to do this involves automating model creation. >> It is >> > > an easy thing to use inverse properties to classify individuals. >> > >> > > But imagine that I have a bunch of 'hasPart somevalues from' and I >> want to >> > > use CONSTRUCT to produce the corresponding 'isPartOf somevaluesfrom' >> without >> > > having to do all of that work. >> > >> > > I will set things up with 3.5x the way that you suggest and see how >> things >> > > work. >> > >> > > I will report what I find. >> > >> > > BTW: I am contemplating an essay that attempts to prove that SPIN is >> sound >> > > and complete, or that it is not. But first I must understand it >> thoroughly. >> > > Plus, the applications that I am working on will need to make use of >> quick >> > > directed reasoning. >> > >> > > Best wishes, >> > > Leonard >> > >> > > On Sat, Jul 16, 2011 at 1:38 PM, Scott Henninger < >> > > [email protected]> wrote: >> > >> > >> Ah, this is a different thread, so I created a new one. This is >> > >> rather unusual, and I'm not clear on why you'd want to do this. The >> > >> normal suggestion is to add the restriction in Composer. That's >> > >> really easy and most flexible, as the ontology designer has control >> of >> > >> what "inverse restrictions" should be applied (this seems to be a >> real >> > >> outlier case). >> > >> > >> However, it seems what you really want is to state is that when a >> > >> classification is found for :hasPart, the inverse should appear >> > >> for :isPartOf. If that's the case, declaring {:isPartOf >> > >> owl:inverseOf :hasPart} will do what you need. I'm assuming in this >> > >> case that you want to end state to be: >> > >> > >> ?auto a :Auto . >> > >> ?wheel a :Wheel . >> > >> ?auto :hasPart ?wheel . >> > >> ?wheel :isPartOf ?auto . >> > >> > >> If that's not the kind of inference you're looking for, then some >> more >> > >> detail on what your goals are would be useful for understanding what >> > >> you are asking. >> > >> > >> -- Scott >> > >> > >> On 7/15/11 3:46 PM, Leonard Jacuzzo wrote: >> > >> > Hi Scott, >> > >> > cls-svf1 is not what I am after. >> > >> > >> > Compare >> > >> > # cls-svf1 >> > >> > CONSTRUCT { >> > >> > ?u a ?x . >> > >> > } >> > >> > WHERE { >> > >> > ?x owl:someValuesFrom ?y . >> > >> > ?x owl:onProperty ?p . >> > >> > ?u ?p ?v . >> > >> > ?v a ?y . >> > >> > } >> > >> > To what I wrote: >> > >> > >> > > CONSTRUCT {?this rdfs:subClassOf ?restriction . >> > >> > > ?restriction rdf:type owl:Restriction . >> > >> > > ?restriction owl:onProperty :isPartOf . >> > >> > > ?restriction owl:someValuesFrom ?Var . } >> > >> > >> > > WHERE { >> > >> > >> > > ?var rdfs:subClassOf ?restriction1 . >> > >> > > ?restriction1 rdf:type owl:Restriction . >> > >> > > ?restriction1 owl:onProperty :hasPart . >> > >> > > ?restriction1 owl:someValuesFrom ?this . >> > >> > > } >> > >> > What I want to do is to create a restriction on one property from a >> > >> restriction on another. In this case I started with 'haspart' being >> > >> restricted to WHEEL and end up with isPart being restricted to auto. >> Where >> > >> Wheel is a subclass of the latter restriction and Auto is a subclass >> of the >> > >> former restriction. >> > >> > >> > Maybe I can explain it better with some thought. >> > >> > >> > Thanks again, I am having fun. >> > >> > LFJ >> > >> > On Fri, Jul 15, 2011 at 4:23 PM, Scott Henninger < >> > >> [email protected]> wrote: >> > >> > >> > See comments inline: >> > >> > >> > > Hi Scott, >> > >> > > Thanks for this. It did not work for me. How is your >> inferencing >> > >> configured? >> > >> > >> > I have TopSPIN configured for inferencing. What didn't work? >> The >> > >> > queries do use some SPARQL 1.1 features that may not be in >> earlier >> > >> > versions of TBC. Upgrading to 3.5.x will work, as will >> replacing IF >> > >> > with smf:if and COALESCE with smf:firstBound. >> > >> > >> > > Also, your rule seems to be constructing a restriction. How >> does >> > >> the inferencing work such that an individual is classified as a >> teenager? >> > >> Does the reasoner construct the restriction and then determine that >> Since >> > >> the individual is a person, and a member of the restriction class, >> and >> > >> teenager is the intersection of Person and The Restriction, the >> individul is >> > >> therefore a teenager? >> > >> > >> > A restriction creates an unnamed node (bnode) that represents a >> > >> > class. In the case of an equivalentClass restriction on a >> class, >> > >> the >> > >> > restriction is an equivalentClass meaning that all members of >> the >> > >> > restriction are also members of the class. E.g. suppose we >> have: >> > >> > :Teenager a owl:Class . >> > >> > <restr> owl:equivalentClass :Teenager >> > >> > >> > The restriction, such as "Person and (hasAge only >> xsd:integer[>= 13 >> > >> , >> > >> > <= 19])" is applied to the class defined by the restriction. >> Since >> > >> it >> > >> > is an equivalent class with :Teenager, then all members of the >> > >> > restriction are members of :Teenager, and vice-versa. >> > >> > >> > > I am trying to get a handle on how SPIN works to perform >> > >> inferences based on OWL semantics. Maybe a more general rule would be >> > >> better. >> > >> > >> > On its own, it doesn't. SPIN is a different way to accomplish >> > >> > inferences. It is based on SPARQL, and as such has no inherent >> > >> > interactions with OWL (it is rdf-based). However, one of the >> OWL 2 >> > >> > profiles, OWL 2 RL, is defined such that a triple-based rule >> engine >> > >> > can implement it directly. SPARQL, using CONSTRUCT, is one >> such >> > >> > engine. When you choose OWL2 RL in the Ontology Home Profile, >> a set >> > >> > of rules implementing OWL 2RL profile are applied when you run >> > >> > inferences. >> > >> > >> > In effect, this imports TopBraid/SPIN/owlrl-all.rdf. For a >> listing >> > >> of >> > >> > these rules, seehttp://topbraid.org/spin/owlrl-all.html. >> Compare >> > >> > these to the standard, >> > >> >> http://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Gra... >> > >> , >> > >> > and you'll see this is a direct implementation the profile. >> > >> > >> > So, as a simpler example, see the cas-sco rule: >> > >> > >> > CONSTRUCT { ?x a ?c2 .} >> > >> > WHERE { >> > >> > ?c1 rdfs:subClassOf ?c2 . >> > >> > ?x a ?c1 . >> > >> > } >> > >> > >> > This is the classic subclassOf inference. If ?x is a member of >> ?c1 >> > >> > and ?c1 is a subClassOf ?c2, then ?x is a member of ?c2. >> > >> > >> > > So instead of classifying an individual, I tried to do some >> class >> > >> level reasoning. For example, If I have a class such as Automobile >> and it is >> > >> defined as a subclass of the restriction on 'Haspart' to some value >> wheel, >> > >> how would a rule that resulted in "wheel isPartOF some Automobile. >> > >> > >> > > So I want to go from >> > >> > >> > > Auto :subClassOf {hasPart some Wheel} >> > >> > >> > > To >> > >> > >> > > Wheel :subClassOf {isPartOf some Automobile} >> > >> > >> > someValuesOf restrictions on someValesOf are already included >> in OWL >> > >> 2 >> > >> > RL, so you don't need to re-implement them. See cls-svf1 and >> cls- >> > >> > svf2. >> > >> > >> > -- Scott >> > >> > >> -- >> > >> 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 > > > -- > 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
