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.

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

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

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


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”


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


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

An answer in the following restriction class has all the questions it enables enabled


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




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




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


we infer

d:TVsymptom a q:EnabledQuestion .

Note that we also have


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: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 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

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


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 3rd kind of restriction is owl:hasValue

Produces a restriction of the form “All individuals having value A for property P”


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


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



owl:hasValue q:Medium] .

q:LowPriorityItem owl:equivalentClass



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

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


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


owl:onProperty mfg:Product_Product_Line;

owl:hasValue "Paper machine"] .

ns:Feedback_Line owl:equivalentClass



owl:hasValue "Feedback line"] .

ns:Active_Sensor owl:equivalentClass



owl:hasValue "Active sensor"] .

ns:Monitor owl:equivalentClass



owl:hasValue "Monitor"] .

ns:Safety_Valve owl:equivalentClass



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;



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


owl:Restriction;



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


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


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


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


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

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.

Documents

answer q

question q

prefix q

whatproblem q

domain q

range q

hasselectedoption of

sboth q