- From: Holger Knublauch <holger@knublauch.com>
- Date: Fri, 23 Apr 2010 12:46:48 +1000
- To: Katasonov Artem <Artem.Katasonov@vtt.fi>, Semantic Web <semantic-web@w3.org>
- Message-Id: <CAE791A5-CEBF-4313-A42E-71C2ACE039E0@knublauch.com>
Hi Artem, On Apr 21, 2010, at 6:13 PM, Katasonov Artem wrote: > Holger, thank you for pointing to SPIN - I was not familiar with this before. > After fast scanning of documentation, I see that SPIN at least > a way of integrating rules with class definitions. > > But are SPIN constructs (spin:restriction probably) assumed to be used AS class definitions? > > Let say, ex:Couple corresponds to > ASK WHERE {?x a ex:Person. ?y a ex:Person. ?x ex:dates ?y} > and then ex:HeterosexualCouple corresponds to > ASK WHERE {?x a ex:Man. ?y a ex:Woman. ?x ex:dates ?y} > or alternatively > ASK WHERE {?x a ex:Person; ex:gender ?xgen. ?y a ex:Person; ex:gender ?ygen. ?x ex:dates ?y. FILTER (?xgen != ?ygen)} > > Can (how) SPIN be used to define ex:HeterosexualCouple through an additional restriction put on ex:Couple? There are many ways of modeling this, depending on your use case. One way would be to have a "global" mapping rule that creates instances of ex:Couple, similar to what Bernard suggested: # Global rule to create instances of ex:Couple CONSTRUCT { _:couple a ex:Couple . _:couple ex:member ?p1 . _:couple ex:member ?p2 . } WHERE { ?p1 ex:dates ?p2 . } This would create (blank node) instances of ex:Couple. You could then attach a further rule to ex:Couple to classify any couple instances according to separate rules: # Classify heterosexual couples CONSTRUCT { ?this a ex:HeteroCouple . } WHERE { ?this ex:member/ex:gender ?gender1 . ?this ex:member/ex:gender ?gender2 . FILTER (?gender1 != ?gender2) . } Above, the variable ?this refers to the instances of ex:Couple. In the example I use SPARQL 1.1 property paths, but the same can be expressed in SPARQL 1.0 as well (albeit a bit verbose). The output will be three triples forming a blank node such as [] a ex:HeteroCouple ; ex:member ex:John , ex:Mary . But all this may not be the right way to work with this model, as I indicated at the end of my previous message. Instead of "inferring" all those triples, you probably just want to ask questions such as "Is John member of a hetero couple"? You don't need to create intermediate objects such as the reified relationship objects above to answer those questions. Just define a SPIN function that gives you a user-friendly vocabulary to ask those questions. For example you can define a function called ex:isHetero with one argument (?arg1) and the following body: # Check whether there is a partner with different gender ASK WHERE { ?arg1 ex:dates ?partner . ?arg1 ex:gender ?gender1 . ?partner ex:gender ?gender2 . FILTER (?gender1 != ?gender2) . } Using SPIN, this allows you to ask SPARQL queries such as ASK WHERE { FILTER ex:isHetero(ex:John) } which returns true in the example. The SPIN engine will execute the upper ASK query whenever ex:isHetero is used in a SPARQL query. This recursive mechanism of building SPARQL queries allows you to do a simple form of backward chaining, computing values on demand. No need to ever create intermediate triples. Those extra inferences may make sense if you want to prevent duplicate computations, but come with the penalty of having to update the inferences on changes. I have attached this example file, which you can open with TopBraid Composer Free edition [1]. The example is not fully worked out, and I am sure there are many variations that could be discussed depending on the actual use case. I do not want to occupy this mailing list here with details on SPIN. For specific follow-up questions, I recommend using the TopBraid Users mailing list [2]. Thanks. And yes, my earlier comment about OWL is mostly about making people aware that OWL is not the answer to everything. It does have its role for certain areas, esp for classification tasks and as a vocabulary for modeling ontology classes. But for many real-world problems we repeatedly find out that OWL is not expressive or performant enough, so that moving up to SPARQL is usually a necessary choice. Regards, Holger [1] http://www.topquadrant.com/products/TB_Composer.html [2] http://groups.google.com/group/topbraid-users
Attachments
- text/html attachment: stored
- application/octet-stream attachment: persons.ttl
- text/html attachment: stored
Received on Friday, 23 April 2010 02:47:36 UTC