basic owl restrictions an owl:restriction is an owl:class defined by describing conditions on the...
TRANSCRIPT
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: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: <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
[ 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
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 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
[ 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 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
[ 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 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”
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 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
[ 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)
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