SPARQL Update for Materialized Triple Stores under DL- Lite RDFS Entailment
RDFS-Plus See D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective...
-
Upload
melvyn-franklin -
Category
Documents
-
view
218 -
download
1
Transcript of RDFS-Plus See D. Allemang and J. Hendler, Semantic Web for the Working Ontologist: Effective...
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
owl:equivalentClass rdfs:subPropertyOf rdfs:subClassOf .
To see how this works, suppose we have
:Analyst owl:equivalentClass :Researcher .
From this and the rdfs:subClassOf rule, we have
:Analyst rdfs:subClassOf :Researcher .
By symmetry, we also have
:Researcher owl:equivalentClass :Analyst.
And, by the rdfs:subClassOf rule again,
:Researcher rdfs:subClassOff :Analyst.
So, given equivalence, we get the double-subClassOf characterization from what’s built in
Equivalence means only that the 2 classes have the same members
Other properties of the classes (e.g., rdfs:label values) aren’t shared
So, if 2 classes are merged from different applications, each application still displays the class by the original print name Only the members change
Equivalent Properties We’ve used the double-subPropertyOf idiom to express that one
property, P, is equivalent to another, Q
P rdfs:subPropertyOF Q .
Q rdfs:subPropertyOf P .
RDFS-Plus also has a simpler way to express property equivalence
P owl:equivalentProperty Q .
For properties P and Q ad individuals x and y, we again have 2 rules:
Given P owl:equivalentProperty Q and x P y, infer x Q y
Given P owl:equivalentProperty Q and x Q y, infer x P y
But, again, these rules can be derived from what is built in
owl:equivalentProperty rdfs:subPropertyOf owl:subPropertyOf .
owl:equivalentProperty a owl:SymmetricProperty .
Starting with
:borrows owl:equivalentProperty :checkedOut .
by the subPropertyOf rule we get
:borrows rdfs:subPropertyOf :checkedOut .
By SymmetricProperty, we also get
:checkedOut owl:equivalentProperty :borrows .
whence, again by the subPropertyOf rule,
:checkeOut rdfs:subPropertyOf :borrows .
Rather than just noticing that the rule governing owl:equivalentProperty is the same as that governing rdfs:subPropertyOf (except it works both ways),
we actually express these facts with triples
By making owl:equivalentProperty a sub-property of rdfs:subPropertyOf, we explicitly assert that they’re governed by the same rule
By making owl:equivalentProperty an owl:SymmetricProperty, we assert that this rule works in both directions
This makes the relationship between the parts of the OWL language explicit and, in fact, models them in OWL
Same Individual owl:equivalentClass and owl:equivalentProperty provide
simple ways to express what’s already expressible in RDFS
They don’t increase the expressive power of RDFS-Plus
Things in the world, members of classes, are called individuals (i.e., real-word resources)
We’ve seen surgeons, plays, countries, playwrights, …
But, in the absence of agreement on global names, different Web authors select different URIs for the same individual
When info from the different sources is brought together in the distributed network of data,
the Web infrastructure has no way to know that certain pairs of names should be treated as denoting the same individual
The flip side is that we can’t assume that, just because 2 URIs are distinct, they denote distinct individuals
The Non-unique Naming Assumption:
We must assume (until told otherwise) that some Web resource might be referred to using different names by different people
When we do determine that 2 individuals are in fact the same, we use the owl:sameAs property
As an example, suppose we have the following triples about the literary career of William Shakespeare:
lit:Shakespeare lit:wrote lit:Hamlet ;
lit:wrote :lit:Othello ;
Etc.
Suppose we have access to the Stratford Parish Register (namespace prefix spr:), with the following baptism info
spr:Gulielmus spr:hasFather spr:JohannesShakspere .
spr:Hamnet spr:hasFather spr:WilliamShakspere .
Etc.
Suppose research finds that spr:Gulielmus, spr:WilliamShakspere, and lit:Shakespeare all refer to the same individual
If we’d known this before representing the Stratford Parish Register in RDF, we could have used the same URI in all cases
But the URIs from each data source have been chosen
We can assert of 2 of the resources
spr:WilliamShakspere owl:sameAs lit:Shakespeare .
The rule for owl:sameAs
Given A owl:sameAs B and a triple containing A, infer a triple that is identical except that A is replaced by B
So, given any triple of the form
spr:WilliamShakspere P O .
we can infer
lit:Shakespeare P O .
And, from any triple of the form
S P spr:WilliamShakespeare .
we can infer
S P lit:Shakespeare .
We also have that owl:sameAs is symmetric
owl:sameAs a owl:SymmetricProperty .
So we can replace any occurrence of lit:Shakespeare with spr:WilliamShakspere as well
We can now infer, e.g.,
spr:WillaimShakspere lit:wrote lit:Hamlet ;
lit:wrote :lit:Othello ;
Etc.
as well as, e.g.,
spr:Hamnet spr:hasFather lit:Shakespeare .
Etc.
Challenge: Merging Data from Different Databases Recall how to interpret info in
a table as RDF triples
Each row becomes an individual
Each cell becomes a triple
The subject is the individual corresponding to the row
The predicate is made up from the table name and the column name
The object is the cell contents
Table 1 shows 63 triples for the 7 columns and 9 rows
Some of the triples relating to Manufacture_Location
mfg:Product1 mfg:Product_Manufacture_Location "Sacramento" .
mfg:Product2 mfg:Product_Manufacture_Location "Sacramento" .
mfg:Product3 mfg:Product_Manufacture_Location "Sacramento" .
mfg:Product4 mfg:Product_Manufacture_Location "Elizabeth" .
mfg:Product5 mfg:Product_Manufacture_Location "Elizabeth" .
Suppose another division in the company keeps a table of the facilities needed to produce various parts—Table 2
Some of the products in Table 1 appear in Table 2 and some don’t
Challenge 19 Using the products in both tables, write a federated query cross-
referencing cities with the facilities required for the production there
Solution If the tables were in a single database, there could be foreign-key
references from one table to the other
We could join the 2 tables
But the tables are from different databases, there’s no such common reference
When we turn the tables into triples, the individuals corresponding to rows are assigned global identifiers
Use namespace p: for the 2nd table
Some of the triples corresponding to the required facilities
p:Product1 p:Product_Facility "Assembly Center" .
p:Product2 p:Product_Facility "Assembly Center" .
p:Product3 p:Product_Facility "Assembly Center" .
p:Product4 p:Product_Facility "Assembly Center" .
p:Product5 p:Product_Facility "Factory" .
The global identifiers aren’t the same, so we need
p:Product1 owl:sameAs mfg:Product4 .
p:Product2 owl:sameAs mfg:Product6 .
p:Product4 owl:sameAs mfg:Product3 .
p:Product5 owl:sameAs mfg:Product1 .
p:Product7 owl:sameAs mfg:Product5 .
p:Product8 owl:sameAs mfg:Product8 .
Now matching the SPARQL pattern
[?p p:Product_Facility ?facility .
?p mfg:Product_Manufacture_Location ?location .]
and displaying ?facility and ?location gives the results in Table 3
The solution relied on knowing which product in one table matched with which in the other
In a real situation, the data in the tables change frequently
Not practical to assert all the owl:sameAs triples by hand
See what follows
Computing Sameness—Functional PropertiesFunctional Properties A functional property can take only 1 value for any given individual
Rule
Given P a owl:FunctionalProperty, x P A, and x P B, infer A owl:sameAs B
Functional properties allow sameness to be inferred
For example, suppose from the Stratford Parish Register we have
lit:Shakespeare fam:hasFather bio:JohannesShakespeare .
and that from Shakespeare’s grave we have
lit:Shakespeare fam:hasFather bio:JohnShakespeare .
If we know from a background model of family relationships that
fam:hasFather a owl:FunctionalProperty
we may infer
bio:JohannesShakespeare olw:sameAs bio:JohnShakespeare .
For determining sameness, owl:InverseFunctionalProperty is much more common than owl:FunctionalProperty
Inverse Functional Properties Some consider owl:InverseFunctionalProperty the most
important modeling construct in RDFS-Plus
Think of owl:InverseFunctionalProperty as the inverse of owl:FunctionalProperty
Rule
Given P a owl:InverseFunctionalProperty, A P x, and B P x, infer A owl:sameAs B
An owl:InverseFunctionalProperty plays the role of a key field in a relational database
Unlike with a relational database, RDFS-Plus doesn’t signal an error if 2 entities are found to share a value for an inverse functional property
Instead, it infers that the 2 are the same
Any identifying number (e.g., SSN, driver’s license number, …) is an inverse functional property
Challenge 20 Infer the requied owl:sameAs triples from the data already asserted
Solution Find an inverse functional property present in both data sets
Use it to bridge them
Tables 1 and 2 both have a field called ModelNo
If 2 products have the same model number, they’re the same product, so
mfg:Product_ModelNo a owl:InverseFunctionalProperty .
Must arrange that we’re talking about a single property
p:Product_ModelNo owl:equivalentProperty mfg:Product_ModelNo .
Could do these steps in either order
And could write the last triple with subject and object reversed
So, since we have, e.g.,
p:Product1 p:Product_ModelNo "B-1430" .
mfg:Product4 mfg:Product_ModelNo "B-1430" .
we may infer
p:Product1 owl:sameAs mfg:Product4 .
Likewise for the remaining sameAs triples
Most real data integration situations rely on more elaborate notions of identity
Include multiple properties and encounter uncertain or ambiguous cases
This problem can often be solved with combinations of OWL properties we’ll explore later
A fully general solution remains a research topic
Combining Functional and Inverse Functional Properties Often useful for a property to be 1-to-1, i.e., both functional and
inverse functional
Often the case for identification numbers
Challenge 21 Assign to students id numbers used for billing and assigning grades
No 2 students should share an id number
No student should have more than 1 id number
Solution Define property hasIdenityNo with the appropriate domain and
range
:hasIdentityNo rdfs:domain :Student .
:hasIdentityNo rdfs:range xsd:Integer .
Enforce uniqueness by asserting
:hasIdentityNo a owl:FunctionalProperty .
:hasIdentityNo a owl:InverseFunctionalProperty .
More RDFS-Plus Constructs The small extensions RDFS-Plus provides greatly increase the
applicability of RDFS
owl:inverseOf combines with rdfs:subClassOf to let us align properties that aren’t expressed in compatible ways in existing data schemas
owl:TransitiveProperty combines with rdfs:subPropertyOf in several novel ways, letting us model various relationships among chains of individuals
From a Semantic Web perspective, the most applicable extensions are those dealing with sameness: sameAs, FunctionalProperty, InverseFunctionalProperty
They provide a way to describe how info from multiple sources is to be merged in a distributed web of info
Classes owl:DataTypeProperty and owl:ObjectProperty let us distinguish between
properties whose values are objects and
properties whose values are a data type
They provide no additional semantics
They provide useful discipline and info for editing tools for, e.g., displaying models
Most OWL tools prefer to distinguish datatype properties (e.g., ship:maidenVoyage) and object properties (e.g., bio:married)
ship:maidenVoyage a owl:DatatypeProperty .
bio:married a owl: ObjectProperty .
Another distinction OWL makes is between rdfs:Class and owl:Class
We’ve been using rdfs:Class but have introduced several OWL constructs to get to RDFS-Plus
Since OWL is based on RDFS, backward compatibility isn’t an issue, and the OWL specification stipulates
owl:Class rdfs:subClassOf rdfs:Class .
Most tools require that classes used in OWL models be declared members of owl:Class
In the RDFS-Plus examples, we’ve left class declarations implicit If explicit, they’d use owl:Class
Most model editors declare a class an owl:class automatically when it’s created
We’ll discuss some subtle distinctions later