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  The new class in turn can be used to describe individuals in a yet newer class  And so on

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

The basic schema for the q:. 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.

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

@prefix d:. 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".

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

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

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

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

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

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

Figure 3 shows these definitions and inferences

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

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

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

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.

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 1 st question indicates such a problem d:STV q:enablesCandidate d:TVsymptom. d:SBoth q:enablesCandidate d:TVsymptom.

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]

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.

See Figure 4 Restrictions are shown here using the Manchester syntax q:enablesCabdidate all q:EnabledQuestion  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

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.

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

Asking this question depends on the answers to the following  Answer to the 1 st ( d:othersinbuilding ) should be d:OYes and to the 2 nd ( 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

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

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

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

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

owl:hasValue The 3 rd 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”

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

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

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

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.

Challenge Problems Challenge: 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.

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.

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

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

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

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

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)

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

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

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.

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

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

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.

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

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

Recall the SKOS rule for managing collections Given X skos:narrower C. C skos:member Y. infer X skos:narrower Y. Where collection C is narrower than concept Y, we can say “Every member of C is narrower than X ”  I.e., the rule governing skos:narrower in the context of a skos:Collection is a relationship transfer

Challenge 25 Using OWL constructs, represent the SKOS rule for propagating skos:narrower in the context of skos:Collection E.g., represent in OWL the constraint If agro:MilkBySourceAnimal skos:member Y. then agro:Milk skos:narrower Y.

Solution First define an inverse of skos:member skos:isMemberOf owl:inverseOf skos:member.  Already have an inverse of skos:narrower in skos:broader Restate the problem with these inverses If Y skos:isMemberOf agro:MilkBySourceAnimal. then Y skos:broader agro:Milk.

To specify that the set of all things Y that are members of agro:MilkBySourceAnimal, use an owl:hasValue restriction agro:MembersOfMilkSource owl:equivalentClass [ a owl:Restriction; owl:onProperty skos:isMemberOf; owl:hasValue agro:MilkBySourceAnimal]. Also specify the set of all things with agro:Milk as broader category agro:NarrowerThanMilk owl:equivalentClass [ a owl:Restriction; owl:onProperty skos:broader; owl:hasValue agro:Milk].

Next, all members of one class are in the other: agro:MembersOfMilkSource rdfs:subClassOf agro:NarrowerThanMilk. Think of this rdfs:subClassOf as like an IF/THEN relation When both subclass and superclass are restrictions, the IF/THEN takes on more meaning, here If an individual skos:isMemberOf agro:MilkBySourceAnimal then that individual (has) skos:broader (concept) agro:Milk With the inverses as defined, this is the same as saying If agro:MilkBySourceAnimal skos:member X. then agro:Milk skos:narrower X.

Relationship Transfer In FOAF A similar situation arises in FOAF with groups Recall that FOAF provides 2 ways to describe members of a group G  Relation foaf:member relates an individual G of foaf:Group to the individuals in G The same G is related to an owl:Class by the foaf:membershipClass property Define a foaf:Group for b:Shakespeares_Children as b:Shakespeares_Children a foaf:Group; foaf:name "Shakespeare's Children"; foaf:member b:Susanna, b:Judith, b:Hamnet; foaf:membershipClass b:ChildOfShakespeare. b:ChildOfShakespeare a owl:Class.

FOAF specifies the rule If b:Shakespeares_Children foaf:member ?x. then ?x rdfs:type b:ChildOfShakespeare. See Figure 10: the result of this rule for our example  Solid lines show asserted triples, dotted lines show inferred triples

Challenge 26 How can we get the inference in Figure 10 using only OWL constructs? Solution This parallels the solution for relationship transfer in SKOS  But here the relationship we’re transferring to is rdfs:type Begin (as before) by defining an inverse of foaf:member b:memberOf owl:inverseOf foaf:member. Using an owl:hasValue restriction, define b:ChildOfShakespeare as the class of all those who are b:memberOf b:Shakespeares_Children b:ChildrenOfShakesoeare a owl:Class; rdfs:label "Child of Shakespeare"; owl:equivalentClass [ a owl:Restriction; owl:hasValue b:Shakespeares_Children; owl:onProperty b:memberOf].

To follow an inference (see Figure 10), assert a triple b:Shakespeares_Children foaf:member b:Hamlet. By the semantics of owl:inverseOf, infer b:Hamnet b:memberOf b:Shakespeares_Children. This satisfies the conditions of the restriction, so infer b:Hamnet rdf:type b:ChildOfShakespeare.

Turn this inference around backward Assert instead b:Hamnet rdf:type b:ChildOfShakespeare. By the semantics of owl:equivalentClass, infer b:Hamnet rdf:type [ a owl:Restriction; owl:hasValue b:Shakespeares_Children; owl:onProperty b:memberOf]. For b:Hamnet to satisfy the restriction, it must be that b:Hamnet b:memberOf b:Shakespeares_Children. By the semantics of owl:InverseOf, infer b:Shakespeares_Children foaf:member b:Hamlet.

Discussion That we can represent something in OWL doesn’t necessitate actually doing so Consider how the solutions just developed compared to those actually taken by the SKOS and FOAF developers SKOS uses a special-purpose rule to define the meaning of skos:narrower in the context of a skos:Concept and a skos:Collection  So a SKOS user can express the relationship between agro:Milk and agro:MilkBySourceAnimal just by asserting agro:Milk skos:narrower agro:MilkBySourceAnimal.  Then the rule takes care of the rest Simpler for the user than constructing the pair of restrictions

SKOS in fact defines the rule more generally Given X P C. P rdf:type skos:CollectableProeprty. C skos:member Y. infer X P Y. skos:CollectableProperty includes skos:narrower, skos:broader, skos:related  So 1 rule expresses constraints for 3 properties To do this with the OWL relationship transfer pattern, we’d have to repeat the pattern once for each property and each concept/collectable pair for which we’re specifying the relationship

But writing a special-purpose rule into to SKOS description has drawbacks We need to define a rule language and a processor for the rules The pragmatic answer:  Rules are written in the natural language used for the specification  Processing is done by each application rather than by a general- purpose inference engine In contrast, an OWL solution  uses generic software  exploits standard semantics The SKOS specification expresses this rule in prose, leaving its implementation to each application

With FOAF, unlike SKOS, there’s only one property ( foaf:membershipClass ) affected by the transfer rule And, in FOAF, a user just asserts one triple b:Shakespeares_Children foaf:membershipClass b:ChildOfShakespeare. for the transfer rule to come into play  This isn’t built into some other construct, like skos:Collection  The FOAF user explicitly indicates where the rule is invoked The ground-up evolutionary strategy of FOAF argues against special-purpose meanings in the specification  Things might change or be superseded

Any FOAF user can already express in OWL the relationship between a foaf:Group and its foaf:members  Or between any class and property as needed This agrees with  the AAA slogan and  the ground-up empowerment of the FOAF user community The SKOS effort is controlled by committee  Can put rules into its specification and control how they interact And SKOS is intended to be used across many domains  SKOS must anticipate that any number of concept/collection pairs might need this rule

In a narrower (“vertical”) domain, some of these conditions may not apply  Most modelers don’t seek W3C recommendation status or other approval as a standard  Rules put into the model might adversely interact with other rules Often in a vertical domain there are few distinguished instances where some part of the model is replicated in another place  Then the relationship transfer is part of the description of these concepts  No need to be repeated indefinitely often

In such cases, it may be just as convenient to describe the relationships using OWL constructs Thus, for group membership in OWL, the modeler makes a very special statement about a group when relating it to its membershipClass Might accept a quite involved way to express this relationship  Especially if done without cluttering the FOAF model itself

Regarding modeling in general One reason to model knowledge in a domain in the first place is to understand  the ramifications of a model  where there are conflicts between one view of the world and another When rules are represented as part of a practice (e.g., encoded into a standard), the rules themselves aren’t available for automated analysis  E.g., suppose a FOAF rule interacted adversely with a SKOS rule How would we know not to use the 2 models together? Later introduce notions of inconsistency and contradiction  See how representations that follow the OWL standard can detect such interactions before their application

Alternative Descriptions of Restrictions Consider traditional terminology sometimes used in talking about OWL restrictions and classes  rdfs:subClassOf can be understood as an if-then relation X rdfs:cubClassOf Y “means” if something is an X then it’s a Y  rdfs:equivalentClass can be understood as an if-and-only-if (iff) relation Given If p then q  p is said to be a sufficient condition for q  q is a necessary condition for p and a partial definition of it

Given p iff q  p is said to be a necessary and sufficient condition of q  And q is a necessary and sufficient condition of p Stick with the OWL terminology  Avoid thorny issues associated with natural language