1 / 70

Basic OWL Restrictions

Basic OWL Restrictions. An owl:Restriction is an owl:Class defined by describing conditions on the individuals it contains This is the basis for extension of models If we can describe a set of individuals in terms of known classes, we can use that description to define a new class

pelham
Download Presentation

Basic OWL Restrictions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Basic OWLRestrictions • An owl:Restriction is an owl:Class defined by describing conditions on the individuals it contains • This is the basis for extension of models • If we can describe a set of individuals in terms of known classes, we can use that description to define a new class • The new class in turn can be used to describe individuals in a yet newer class • And so on

  2. Example: Questions and Answers • Running example: managing questions, as for a questionnaire or (when correct answers provided) a quiz • Questions and answers both include string data • Selection of an answer to a question may preclude posing certain following questions • Use namespace q: for elements relating to questionnaires in general • Use d: for elements of the particular example questionnaire

  3. The basic schema for the questionnaire @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix q: <http://www.aboutq.org/vocabulary#> . q:Answer a owl:Class . q:Question a owl:Class . q:optionOf a owl:ObjectProperty; rdfs:domain q:Answer; rdfs:range q:Question; owl:inverseOf q:hasOption . q:hasOption a owl:ObjectProperty . q:answerText a owl:DatatypeProperty; rdfs:domain q:Answer; rdfs:range xsd:string . q:questionText a owl:FunctionalProperty, owl:DatatypeProperty; rdfs:domain q:Question; rdfs:range xsd:string .

  4. Consider a questionnaire that’s part of the screening for the helpdesk of a cable TV and Internet provider Question: What system are you having trouble with? • Possible answers (3): Cable TV, High-Speed Internet, Both Question: What TV symptom(s) are you seeing? • Possible answers (4): No Picture, No Sound, Tiling, Bad Reception

  5. @prefix d: <http://www.fredservice.org/helpdesk#> . d:WhatProblem a q:Question; q:hasOption d:STV, d:SInternet, d:SBoth; q:questionText "What system are you having trouble with?" . d:STV a q:Answer; q:answerText "Cable TV" . d:SInternet a q:Answer; q:answerText "High-speed Internet" . d:SBoth a q:Answer; q:answerText "Both" . d:TVsymptom a q:Question; q:questionText "What TV symptoms are you having?"; q:hasOption d:TVSnothing, d:TVSnosound, d:TVStiling, d:TVSreception . d:TVSnothing a q:Answer; q:answerText "No Picture" . d:TVSnosound a q:Answer ; q:answerText "No Sound" . d:TVStiling a q:Answer; q:answerText "Tiling" .

  6. Consider how we’d record answers to the questions • Define subproperty q:hasSelectedOption of q:hasOption q:hasSelectedOption a owl:ObjectProperty; rdfs:subPropertyOf q:hasOption . • When the user answers a question, a triple is entered to indicate the option selected • E.g., if the user selects “Cable TV” for question d:WhatProblem, we add to the store d:WhatProblem q:hasSelectedOption d:STV . • No need to remove any triple from the store • The original q:hasOption relationship between d:whatProblem and d:STV still holds

  7. Adding Restrictions • The OWL construct for creating class descriptions based on descriptions of prospective class members is owl:Restriction • A subclass of owl:Class • Defined by a description of its members in terms of existing properties and classes • The class of all things, owl:Thing is unrestricted—see the AAA slogan • Define a owl:Restriction with a description restricting the kinds of things that can be said about class members • E.g., given property :orbitsAround, can say anything :orbitsAround anything else • Restricting the value of :orbitsAround by saying its object must be :TheSun defines the class of all things orbiting around the sun

  8. Three of the restrictions are owl:allValuesFrom, owl:someValuesFrom, owl:hasValue • Keyword owl:onProperty specifies the property used in the definition of the restriction class • E.g., for the restriction defining the objects orbiting around the sun, use owl:onProperty orbitsAround • Membership in a restriction class must satisfy the conditions given by the kind of restriction and the owl:onProperty specification

  9. owl:someValuesFrom • owl:someValuesFrom produces a restriction of the form “All individuals for which at least 1 value of property P comes from class C” • E.g., define a class for all-star players as “All individuals for which at least 1 value of property :playsFor comes from class :AllStarTeam” [ a owl:Restriction; owl:onProperty :playsFor; owl:someValuesFrom :AllStarTeam] • The subject of all 3 triples here is a bnode—something is a restriction class defined on property :playsFor requiring … • There’s no name for the restriction class (yet)—it’s an “unnamed class” • If an individual actually has some value from class :AllStarTeam for property :playsFor, then it’s in this restriction class

  10. Example: Answered Questions • Recall • property q:hasOption (relating a question to an answer option) and • its subproperty q:hasSelectedOption (those answers selected) • Now address the problem of selecting which question to ask • Usually don’t ask a question for which we already have an answer • An answered question is one with some value from class q:Answer for property q:hasSelectedOption q:AnweredQuestion owl:equivalentClass [ a owl:Restriction; owl:onProperty q:hasSelectedOption; owl:someValueFrom q:Anwer] .

  11. Given the asserted triples d:WhatProblem q:hasSelectedOption d:STV . d:STV a Answer . individual d:WhatProblem satisfies the conditions of the restriction class so is a member of class q:AnsweredQuestion • The inference is: Given d:WhatProblem a [ a owl:Restriction; owl:onProperty q:hasSeelctedOption; owl:someValueFrom q:Anwer] . • by the semantics of owl:equivalentClass infer d:WhatProblem a AnsweredQuestion

  12. Figure 3 shows these definitions and inferences

  13. owl:allValuesFrom • owl:allValuesFrom produces a restriction class of the form “the individuals for which all values of property P come from class C” [ a owl:Restriction; owl:onProperty P; owl:allValuesFrom C] • If individual x is a member of this restriction, then every value of property P for x is inferred to be in class C

  14. E.g., suppose :myFavoriteAllStarTeam (a member of class :BaseballTeam) is a member of [ a owl:Restriction; owl:onProperty :hasPlayer; owl:allValuesFrom :StarPlayer] • Then every player on :MyFavoriteAllStarTeam is a :StarPlayer • E.g., suppose further that we have the triples :MyFavoriteAllStarTeam :hasPlayer :Gonzales . :MyFavoriteAllStarTeam :hasPlayer :Kaneda . • Then both :Kaneda and :Gonzales are of type :StarPlayer

  15. owl:someValueFrom is defined as a restriction class such that there’s at least 1 member of a class with a given property • So it implies there is such a member • owl:allValuesFrom technically means “if there are any members of the class, then they all must have the property” • This doesn’t imply that there are any members

  16. Example: Question Dependencies • For our questionnaire, we ask certain questions only after particular answers are given • First define the class of all selected answers based on the q:hasSelectedOption property • Define a class for the selected answers and ensure that any option that’s been selected appears in the class q:SelectedAnswer a owl:Class; rdfs:subClassOf q:Answer . q:hasSelectedOption rdfs:range q:SelectedAnswer . • Introduce class q:EnabledQuestion of questions that can be asked (after selected answers have been given) q:EnabledQuestion a owl:Class .

  17. An answer enables a question (property q:enablesCandidate) if selecting that answer causes the system to consider that question as a candidate for the next question asked q:enablesCandidate a owl:ObjectProperty; rdfs:domain q:Answer; rdfs:range q:Question . • E.g., ask a question about TV problems only if the answer to the 1st question indicates such a problem d:STV q:enablesCandidate d:TVsymptom . d:SBoth q:enablesCandidate d:TVsymptom .

  18. An answer in the following restriction class has all the questions it enables enabled [ a owl:Restriction; owl:onProperty q:enablesCandidate; owl:allValuesFrom q:EnabledQuestion] • Any member of q:SelectedAnswer should also be a member of this restriction class q:SelectedAnswer rdfs:subClassOf [ a owl:Restriction; owl:onProperty q:enablesCandidate; owl:allValuesFrom q:EnabledQuestion]

  19. Follow out an example • When the user selects answer “Cable TV” for the first question, we assert d:STV a q:SlectedAnswer . • Because of the subclass relation, d:STV is also in the restriction class d:STV a [ a owl:Restriction; owl:onProperty q:enablesCandidate; owl:allValuesFrom q:EnabledQuestion] • For any answer x that’s a member of this restriction, any question related to x by q:enablesCandidate must be a member of q:EnabledQuestion • Since d:STV q:enablesCandidate d:TVsymptom . we infer d:TVsymptom a q:EnabledQuestion . • Note that we also have d:SBoth q:enablesCandidate d:TVsymptom .

  20. Summarizes a restriction using keywords all, some, and hasValue to indicate restriction types • The restriction property appears before the keyword • The target class (or, for owl:hasValue, individual) appears after the keyword • See Figure 4 • Restrictions are shown here using the Manchester syntax q:enablesCabdidate all q:EnabledQuestion

  21. If we extend the example with another question about Internet symptoms d:InternetSymptoms, we express all dependencies as d:STV q:enablesCandidate d:TVsymptom . d:SBoth q:enablesCandidate d:TVsymptom . d:SBoth q:enablesCandidate d:Internetsymptom . d:SInternet q:enablesCandidate d:Internetsymptom .

  22. Example: Prerequisites • We’ve supposed that answering one question makes all dependent questions eligible • Questions are also related as prerequisites • All a question’s prerequisites must be answered appropriately for it to be eligible • Triples defining part of a questionnaire d:NeighborsToo a q:Question; q:hasOption d:NTY, d:NTN, d:NTDK; q:QuestionText "Are other customers in your building also experiencing problems?" . d:NTY a q:Answer; q:answerText "Yes, my neighbors are experiencing the same problem." . d:NTN a q:Answer; q:answerText "No, my neighbors are not experiencing the same problem." . d:NTDK a q:Answer; q:answerText "I don’t know." .

  23. Asking this question depends on the answers to the following • Answer to the 1st (d:othersinbuilding) should be d:OYes and to the 2nd (d:whatissue) should be d:PTech d:othersinbuilding a q:Question; q:hasOption d:ONo, d:OYes; q:questionText "Do you live in a multi-unit dwelling with other customers?" . d:OYes a q:Answer; q:answerText "Yes." . d:ONo a q:Answer; q:answerText "No." . Continued

  24. d:whatIssue a q:Question; q:hasOption d:PBilling, d:Pnew, d:PCancel, d:PTech; q:questionText "What can customer service help you with today?" . d:PBilling a q:Answer; q:answerText "Billing question" . d:PNew a q:Answer; q:answerText "New account" . d:PCancel a q:Answer; q:answerText "Cancel account" . d:PTech a q:Answer; q:answerText "Technical difficulty" . • See Fig. 6 for a graphical version

  25. Challenge 22 • Model the relationship between d:NeighborsToo, d:whatIssue, d:othersinbuilding So we ask d:NeighborsToo only when we have appropriate answers to the other 2 • Introduce a property to relate a question to its prerequisites q:hasPrerequisite a rdf:Property; rdfs:domain q:Question; rdfs:range q:Answer . • Indicate the relationship between questions using this d:NeighborsToo q:hasPrerequisite d:PTech, d:OYes . • See Figure 7

  26. Now say that we infer something is a d:EnabledQuestion if all its prerequisite answers are selected • First assert [ a owl:Restriction; owl:onProperty q:hasPrerequisite; owl:allValuesFrom q:SelectedAnswer] rdfs:subClassOf q:EnabledQuestion . • For individual x to satisfy this restriction, every time there’s a triple x q:hasPrerequisite y . y must be a member of d:SelectedAnswer

  27. But, by the Open World Assumption, we don’t know whether there’s another triple of this form where y isn’t in d:SelectedAnswer • The rest of this challenge must wait until we discuss the ways we can (partially) close the world in OWL • Basic idea: If we can say how many prereqs a question has, then we’ll know when all have been selected

  28. owl:hasValue • The 3rd kind of restriction is owl:hasValue • Produces a restriction of the form “All individuals having value A for property P” [ a owl:Restriction; owl:onProperty P; owl:hasValue A] • A special case of the owl:someValuesFrom restriction where class C is singleton set {A} • Distinguished since it’s a common and useful modeling form • Turns a description of a specific instance into a class description • E.g., can define • “The set of all planets orbiting the sun” • “The set of all baseball teams in Japan”

  29. Example: Priority Questions • We assign priority levels to our questions • First define a class of priority levels and the individual levels q:PriorityLevel a owl:Class . q:High a q:PrioirtyLevel . q:Medium a q:PrioirtyLevel . q:Low a q:PrioirtyLevel . • Then define a property for the priority level (e.g., of a question) q:hasPriority a rdf:Property; rdfs:range q:PriorityLevel . • Don’t give a domain—things other than questions have priorities

  30. Now define the class of high-priority items q:HighPriorityItem owl:equivalentClass [ a owl:Restriction; owl:onProperty q:hasPriority; owl:hasValue q:High] . • Since we’ve used owl:equivalentClass, we’ve effectively named this restriction class

  31. Do the same with medium and low priority classes q:MediumPriorityItem owl:equivalentClass [ a owl:Restriction; owl:onProperty q:hasPriority; owl:hasValue q:Medium] . q:LowPriorityItem owl:equivalentClass [ a owl:Restriction; owl:onProperty q:hasPriority; owl:hasValue q:Low] .

  32. Suppose we assert the priority levels of some questions d:WhatProblem q:hasPritority q:High . d:InternetSymptom q:hasPriority q:Low . Can infer d:whatProblem a q:HighPriorityItem . d:InternetSymptom a q:LowPriorityItem . • Can draw inferences in the other direction too • E.g., suppose we assert d:TVsymptom a q:HighPriorityItem . • By the semantics of owl:equivalentClass, infer that d:TVsymptom is a member of the restriction class and bound by its stipulations • So infer d:TVsymptom q:hasPriority q:High .

  33. Challenge ProblemsChallenge: Local Restriction of Ranges • Saw rdfs:domain and rdfs:range to classify data according to use • In more elaborate modeling situations, finer granularity of domain and range inferences are needed • E.g., describing a vegetarian diet :Person a owl:Class . :Food a owl:Class . :eats rdfs:domain :Person . :eats rdfs:range :Food . • Instance data :Maverick :eats :Steak .

  34. From this schema and instance, infer :Maverick a :Person . :Steak a :Food . • Define a variety of diets in more detail • E.g., a kind of person, :Vegetarian, who eats a particular kind of food, :Vegetarian food :Vegetarian a owl:Class; rdfs:subClassOf :Person . :VegetarianFood a owl:Class; rdfs:subClassOf :Food .

  35. Suppose also :Jen a :Vegetarian; :eats :Marzipan . • We’d like to be able to infer :Marzipan a :VegetarianFood . but not make the corresponding inference for Maverick’s steak

  36. Challenge 23 • If we assert :eats rdfs:domain :Vegetarian . :eats rdfs:range :VegetarianFood . could make the unwanted inferences to :Maverick a :Vegetarian . :Steak a :VegetarianFood . • Correctly model the relationship between vegetarians and vegetarian food

  37. Solution • Define the set of things that eat only :VegetarianFood using a owl:allValuesFrom restriction • Then assert, using owl:subClassOf, that any :Vegetarian satisfies this condition :Vegetarian rdfs:subClassOf [ a owl:Restriction; owl:onProperty :eats; owl:allValuesFrom :VegetarianFood] .

  38. Then, since :Jen a :Vegetarian . infer :Jen a [ a owl:Restriction; owl:onProperty :eats; owl:allValuesFrom :VegetarianFood] . • Combined with :Jen :eats :Marzipan . infer :Marzipan a :VegetarianFood . • There’s no stated relationship between :Maverick and :Vegetarian • Nothing on which to base an inference • See Figure 9

  39. Challenge: Filtering Data Bases on Explicit Type • We’ve seen how tabular data can be used in RDF • Each row is an individual • Column names are properties • Values in the table are values • See table 1 (repeated from earlier)

  40. Each individual has the same type, mfg:Product, from the name of the table

  41. Limited number of possible values, known in advance, for “Product Line” field: “Paper machine”, “Feedback line”, “Safety valve”, etc. • A more elaborate way to import this info is to • still have one individual per table row but • have rows with different types depending on value of Product Line column • E.g., mfg:Product1 rdf:type ns:Paper_machine . mfg:Product1 rdf:type ns:Feedback_line . mfg:Product1 rdf:type ns:Monitor . mfg:Product1 rdf:type ns:SafetyValue . • With a single method for importing tables, all rows become individuals of the same type • A software intensive solution is to write a more elaborate import mechanism • Lets a user specify which column specifies the type • A model-based solution uses an OWL model and an inference engine

  42. Challenge 24 • Build an OWL model letting us infer type info from each individual, based on the value in the “Product Line” field • Use just the simple imported triples seen earlier Solution • The classes for the rows are already known ns:Paper_Machine rdf:type owl:Class . ns:Feedback_Line rdf:type owl:Class . ns:Active_Sensor rdf:type owl:Class . ns:Monitor rdf:type owl:Class . ns:Safety_Valve rdf:type owl:Class .

  43. Now the class constructors ns:Paper_Machine owl:equivalentClass [ a owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Paper machine"] . ns:Feedback_Line owl:equivalentClass [ a owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Feedback line"] . ns:Active_Sensor owl:equivalentClass [ a owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Active sensor"] .

  44. ns:Monitor owl:equivalentClass [ a owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Monitor"] . ns:Safety_Valve owl:equivalentClass [ a owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Safety_Valve"] .

  45. For inferences, consider mfg:Product1 (“ZX-3”) • The following triple has been imported from the table mfg:Product1 mfg:Product_Product_Line "Paper machine" . • So mfg:Product1 satisfies the condition on the restriction for Paper_Machine, so can infer mfg:Product1 rdf:type [ owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Paper machine"] . • By the semantics for owl:equivalentClass, infer mfg:Product1 rdf:type mns:Paper_Machine .

  46. And the definition maintains coherence of the date even from new source • E.g., suppose a new product is defined with os:ProductA a mfg:Paper_Machine . • The semantics of owl:euivalentClass means that all members of mfg:Paper_Machine are also members of the restriction, so os:ProductA a [ a owl:Restriction; owl:Restriction; owl:onProperty mfg:Product_Product_Line; owl:hasValue "Paper machine"] . • By the semantics of the restriction, infer os:ProductA mfg:Product_Product_Line "Paper Machine" . • Regardless of how product info is brought into the system, it’s represented consistently in terms of both rdf:type and mfg:Product_Product_line

  47. Challenge: Relationship Transfer in SKOS • When mapping from one model to another, often say something of the form “Everything related to A by property p should also be related to B by property q” • E.g., “Everyone who plays for the All Star team is governed by the league’s contract” “Every work in the Collected Works of Shakespeare was written by Shakespeare” • This kind of mapping is relationship transfer: transfer individuals in a relationship with one entity to another relationship with another entity

More Related