RDFS-Plus See D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL , Morgan Kaufmann, 2008 Present a subset of OWL, RDFS-Plus, for several reasons: Pedagogically, these constructs are a gentle addition to those already familiar from RDFS Practically, this set of constructs has considerable utility More case studies use RDFS-Plus than RDFS alone Computationally, this OWL subset can be implemented using a wide variety of inferencing technologies Lessens the dependency of the Semantic Web on any particular technology.
64
Embed
RDFS-Plus See D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL, Morgan Kaufmann, 2008 Present a.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
RDFS-Plus See
D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL, Morgan Kaufmann, 2008
Present a subset of OWL, RDFS-Plus, for several reasons:
Pedagogically, these constructs are a gentle addition to those already familiar from RDFS
Practically, this set of constructs has considerable utility More case studies use RDFS-Plus than RDFS alone
Computationally, this OWL subset can be implemented using a wide variety of inferencing technologies Lessens the dependency of the Semantic Web on any
particular technology.
RDFS-Plus (like RDF) is expressed entirely in RDF
The new resources are in namespace owl
Their meanings (as in RDFS) are specified by the rules governing inferences made with them
As with RDFS, the actions of an inference engine combine features of the schema language in novel ways
Inverse If a relationship (e.g., hasParent) is interesting enough to mention,
there’s probably another (e.g., hasChild) that’s also interesting
The inverse of a property is another property that reverse its direction
The rule:
Given P owl:inverseOf Q and x P y infer y Q x
E.g., given
lit:Shakespeare lit:wrote lit:Macbeth .
lit:Macbeth lit:setIn geo:Scotland .
and
lit:wrote owl:inverseOf lit:writtenBy .
lit:setIn owl:inverseOf lit:settingFor .
infer
lit:Macbeth lit:writtenBy lit:Shakespeare .
geo:Scotland lit:settingFor lit:Macbeth .
But the effect of inverseOf can be achieved just as easily by writing queries differently
E.g., to find the plays setIn Scotland, use the inverse property settingFor in a query pattern:
[geo:Scotland lit:settingFor ?play . ]
But can avoid the inverse property and just write
[?play lit:setIn geo:Scotland . ]
Challenge: Integrating Data that Do Not Want to be Integrated In the Property Union challenge, we had 2 properties, borrows and
checkedOut
Combined them under a single property by making them both sub-properties of hasPossession
Lucky the 2 data sources had the same domain (Patron) and range (Book)
But suppose the domain and range of the 2nd data source are reversed:
It’s an index of books; for each book, there’s a field for the patron the book is signedTo
Challenge 10 Merge signedTo and borrows as we merged borrows and
checkedOut
Solution Use owl:inverseOf so the domains and ranges do match
Define a new property as the inverse of signedTo:
:signedTo owl:inverseOf :signedOut .
Now use the original Property Union pattern to merge signedOut and borrows:
:signedOut rdfs:subPropertyOf :hasPossession .
:borrows rdfs:subPropertyOf :hasPossession .
Given the triples
:Amit :borrows :MobyDick .
:Marie :borrows :Orlando .
:LeavesOfGrass :signedTo :Jim .
:WutheringHeights :signedTo :Yoshi .
then, with the rule for inverseOf, we infer
:Jim :signedOut :MobyDick .
:Yoshi :signedOut :WutheringHeights .
and, with subPropertyOf, we have (as desired)
:Amit :hasPossessionOf :MobyDick .
:Marie :hasPossession :Orlando .
:Jim :hasPossession :LeavesOfGrass .
:Yoshi :hasPossession :WutheringHeights .
Solution (Alternative) The choice to specify an inverse for signedTo rather than for
hasPossession was somewhat arbitrary
Use the same rules for owl:inverseOf and rdfs:subPropertyOf
in a different order but
resulting in the same hasPossession triples
:signedTo rdfs:subPropertyOf :possessedBy .
:borrows rdfs:subPropertyOf :hasPossession .
:possessedBy owl:inverseOf :hasPossession .
We want to support not only desired inferences but also reuse
A future query could be interested in hasPossession or in possessedBy
And we might later wish to combine hasPossession or possessedBy with another property
So we might use both solutions together by using inverseOf and subPropertyOf systematically: Specify inverses for every property, regardless of subProperty level
:signedTo owl:inverseOf :signedOut .
:signedTo rdfs:subPropertyOf :possessedBy .
:signedOut rdfs:subPropertyOf :hasPossession .
:lentTo owl:inverseOf :borrows .
:lentTo rdfs:subPropertyOf :possessedBy .
:borrows rdfs:subPropertyOf :hasPossession .
:possessedBy owl:inverseOf :hasPossession .
Fig. 1 displays the systematic nature of this structure
Shouldn’t there be owl:inverseOf arrows point right-to-left as well as those point left-to-right in Fig. 1?
Yes, but we needn’t assert them—see the next challenge
Challenge: Using the Modeling Language to Extend the Modeling Language Extra OWL features beginners find missing often can be supported by
OWL as a combination of other features
Challenge 11 Define a superClassOf property, so the parent class is the subject of all
definitional triples Use namespace myowl for this relation,
:Food myowl:superClassOf :bakedGood;
myowl:superClassOf :Confextionary;
myowl:superClassOf :PackagedFood;
myowl:superClassOf :PreparedFood;
myowl:superClassOf :ProcessedFood .
With rdfs:subClassOf, all triples would go the other way
Solution For any triple of the form
P myowl:superClassOf Q .
we want to be able to infer
Q rdfs:subClassOf P .
Do this simply by declaring an inverse:
myowl:superClassOf owl:inverse rdfs:subClassOf .
Beginners often think they have no right
to extend the meaning of the OWL language or
to make statements about the OWL and RDFS resources (e.g., rdfs:subClassOf)
In fact, the standards don’t prevent us from putting the subject of the above in the RDFS namespace:
rdfs:superClassOf owl:inverse rdfs:subClassOf .
But referring to a resource in the RDFS namespace suggests to a human reader of the model that this relation is part of the RDFS standard
Selecting namespaces for resources that extend OWL is a delicate matter
Challenge: The Marriage of Shakespeare Earlier, we could assert that Anne Hathaway married Shakespeare
but couldn’t assert that Shakespeare married Anne
Challenge 12 Infer marriages in the reverse direction from that in which they’re
asserted
Solution Just declare bio:married to be its own inverse:
bio:married owl:inverse bio:married .
Now a triple using bio:married is automatically inferred to hold in the other direction
E.g., given
bio:AnneHatheway bio:married lit:Shakespeare .
we can infer
lit:Shakespeare bio:married bio:AnneHathaway .
This pattern of self-inverses is so common that it’s built into OWL using special construct owl:SymmetricProperty
Symmetric Properties Unlike owl:inverseOf (a property relating 2 other properties),
owl:SymmetricProperty is an aspect of a single property
Expressed as a class
P a owl:SymmetricProperty .
From this, infer
P owl:inverseOf P .
E.g., we can assert
bio:married a owl:SymmetricProperty .
Using OWL to Extend OWL In Fig. 1, all inverses go in one direction
But we need them to go in both directions—see Fig. 2
We asserted left-to-right triples:
:possessedBy owl:inverseOf :hasPossession .
:signedTo owl:inverseOf :signerOut .
:lentTo owl:inverseOf :borrows .
We want to be able to infer right-to-left triples:
:hasPossession owl:inverseOf :possessedBy .
:signedOut owl:inverseOf :signedTo .
:borrows owl:inverseOf :lentTo .
Challenge 13 Infer these triples without having to assert them
Solution We want owl:inverseOf to work in both directions, i.e., to be its
own inverse:
owl:inverseOf owl:inverseOf owl:inverseOf .
A more readable and understandable way of saying the same is
owl:inverseOf a olw:SymmetricProperty .
In either case, we get the bidirectional inverses of Fig. 2
Transitivity In math, relation R is transitive if R(a,b) and R(b,c) implies R(a,c)
Like owl:SymmetricProperty, owl:TransitiveProperty is a class of properties P a owl:TransitiveProperty .
Rule:
Given P a owl:TransitiveProperty, x P y, and y P z,
infer x P z
Using transitivity repeatedly, we can pull together the start and end individuals of a chain of individuals related by a transitive property P
Given x0 P x1, x1 P x2, …, and xn-1 P xn, infer x0 P xn
Typical examples of transitive properties include
Ancestor/descendant:
If x is an ancestor of y and y is an ancestor of z then x is an ancestor of z
Geographical containment:
If Tokyo is in Japan and Japan is in Asia, then Tokyo is in Asia
Challenge: Relating Parents to Ancestors A model of genealogy includes parents and ancestors
We’d like them to fit together
But ancestors are transitive while parents aren’t
Challenge 14 Allow a model to maintain consistent ancestry info, given parentage
info
Solution First define the parent property to be a subPropertyOf the ancestor
property:
:hasParent rdfs:subPropertyOf :hasAncestor .
Then declare ancestor (only) to be transitive:
:hasAncestor a owl:TransitiveProperty .
E.g., assert
:Alexia :hasParent :WillemAlexander .
:WillemAlexander :hasParent :Beatrix .
:Beatrix :hasParent :Wilhelmina .
Because of
the subPropertyOf relation between hasParent and has hasAncestor and
the fact that hasAncestor is transitive,
we can infer what’s on the next slide (see Fig. 3)
:Alexia :hasAncestor :WillemAlexander .
:WillemAlexander :hasAncestor :Beatrix .
:Alexia :hasAncestor :Beatrix .
:WillemAlexander :hasAncestor :Wilhelmina .
:Alexia :hasAncestor :Wilhelmina .
Info about the heritage is integrated, whether it originated with hasParent or with hasAncestor
But info about hasParent is only available as asserted—not transitive
Challenge: Layers of Relationships It’s sometimes controversial whether a property is transitive
E.g., Favre’s thumb is part of Favre and Favre is part of the Vikings, but …
To anticipate possible uses of the model, support both points of view when controversy might arise
Challenge 15 Simultaneously maintain transitive and non-transitive versions of
part of info
Solution Define 2 versions of the partOf property in different namespaces
(or with different names) with
one a subPropertyOf the other and
the super-property declared transitive
dm:partOf rdfs:subPropertyOf gm:partOf .
gm:partOf a owl:TransitiveProperty .
Depending on which interpretation of partOf an application needs, it can query the appropriate property
Managing Networks of Dependencies Now see how the constructs rdfs:subPropertyOf, owl:inverseOf,
and owl:transitiveProperty can be combined to model aspects of networks of dependencies
In workflow management, the sequence of tasks in a complex working situation is represented explicitly
The progress of each task is tracked in that sequence
Workflow is modeled in a Semantic Web so that parts of it can be shared with others
This encourages reuse, review, and publication of work fragments
Take a simple example: making ice cream Slice a vanilla bean lengthwise, scraping the contents into 1 cup of
heavy cream Bring the mixture to a simmer (but don’t boil)
While the cream is heating … Separate 3 eggs Add ½ cup white sugar Beat until fluffy
Then … Gradually add the warm cream, beating constantly Return the custard mixture to medium heat, and cook until mixture
leaves a heavy coat on the back of a spatula Chill well Combine custard with 1 cup whole milk Turn in ice cream freezer according to manufacturer’s instructions
Property dependsOn represents dependencies between steps
Its inverse is enables
:SliceBean :enables :HeatCream .
:SeparateEggs :enables :AddSugar .
:AddSugar :enables :BeatEggs .
:BeatEggs enables :GraduallyMix .
:HeatCream :enables :GraduallyMix .
:GraduallyMix :enables :CookCustard .
:CookCustard :enables :Chill .
:Chill :enables :AddMilk .
:AddMilk :enables :TurnInFreezer .
Challenge 16 For a given step, we’d want to know
all the steps it depends on or all that depend on it
Solution Use the
subPropertyOf/TransitiveProperty pattern for both dependsOn and enables (see Fig. 6):
:dependsOn rdfs:subPropertyOf :hasPrerequisite .
:hasPrerequisite a owl:TransitiveProperty .
:enables rdfs:subPropertyOf :prerequisiteFor .
:prerequisiteFor a owl:TransitiveProperty .
We can then infer, e.g., that GraduallyMix has 5 prerequisites:
:GraduallyMix :hasPrerequisite :AddSugar ;
:hasPrerequisite :SeparateEggs ;
:hasPrerequisite :SliceBean ;
:hasPrerequisite :HeatCream ;
:hasPrerequisite :BeatEggs .
Challenge 17 In a realistic setting, we’d manage several interacting processes and
might even lose track of what steps are in the same procedure
In the recipe example, can we connect the steps in the same recipe together?
Solution Combine both fundamental relationships (enables and dependsOn) as
common sub-properties of neighborStep Make neighborStep a sub-property of a transitive property,
inSameRecipe
:dependsOn rdfs:subPropertyOf :neighborStep .
:enables rdfs:subPropertyOf :neighborStep .
:neighborStep rdfs:subPropertyOf :inSameRecipe .
:inSameRecipe a owl:TransitiveProperty .
Any step directly related (related by dependsOn or enables) to another step has that step as a neighborStep
Any combination of neighbors is rolled up with inSameRecipe
In fact, any 2 steps here will be related by inSameRecipe
This includes relating each step to itself—e.g.,
:GraduallyMix :inSameRecipe :GraduallyMix .
This might not be what we want
Challenge 18 Define a property that relates a recipe only to the other steps in the
same recipe
Solution Earlier defined properties hasPrerequisite (looking downstream
along the dependencies) and prerequisiteFor (looking upstream):
:dependsOn rdfs:subPropertyOf :hasPrerequisite .
:hasPrerequisite a owl:TransitiveProperty .
:enables rdfs:subPropertyOf :prerequisiteFor .
:prerequisiteFor a owl:TRansitiveProperty .
Now join these under a common super-property that isn’t transitive:
:hasPrerequisite rdfs:subPropertyOf :otherStep .
:prerequisiteFor rdfs:subPropertyOf :otherStep .
We’ve already seen the triples we can infer for hasPrerequisite involving GradualyMix
:GraduallyMix :hasPrerequisite :AddSugar ;
:hasPrerequisite :SeparateEggs ;
:hasPrerequisite :SliceBean ;
:hasPrerequisite :HeatCream ;
:hasPrerequisite :BeatEggs .
For prerequisiteFor, we get
:GraduallyMix :prerequisiteFor :AddMilk ;
:prerequisiteFor :CookCustard ;
:prerequisiteFor :TurnInFreezer ;
:prerequisiteFor :Chill .
For otherStep, the set of triples involving GraduallyMix is just the union of the above 2 sets
There is no reflexive triple
Fig. 7 shows the 2 patterns
For inSameRecipe, a single transitive property is at the top of the subproperty tree
Both primitive properties are brought together
Any combinations of the resulting property (neighborStep) are chained together as a transitive property (inSameRecipe)
For otherStep, the top property itself isn’t transitive
It’s a simple combination of 2 transitive properties
Inference for each is done separately, and the results combined
Equivalence In RDF, the URI provides global identity, valid across data sources
Lets us refer to a single entity in a distributed way
But suppose we have info from multiple sources controlled by multiple stakeholders
Stakeholders might use different URIs to refer to the same entity
In a federated setting, want to stipulate that 2 URIs actually refer to the same entity
Equivalent Classes We’ve used the double-subClassOf idiom to express that one class,
A, has the same elements as another, B
A rdfs:subClassOf B .
B rdfs:subClassOf A .
When 2 classes are known always to have the same members, they’re equivalent
RDFS-Plus has a simpler way to express equivalence of classes
A owl:equivalentClass B .
For classes A and B and individual x, we have 2 rules:
Given A owl:equivalentClass B and x a A, infer x a B
Given B owl:equivalentClass A and x a B, infer x a A
But the following is given
owl:equivalentClass a owl:SymmetricProperty .
So we don’t need the 2nd rule—infer it from the 1st
We don’t even need the 1st rule since it’s also given that