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 .


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



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:


: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: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:Product5 p:Product_Facility "Factory" .

The global identifiers aren’t the same, so we need

p:Product1 owl:sameAs mfg:Product4 .






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


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

rdfs-plus see d. allemang and j. hendler, semantic web for the working ontologist: effective...

Documents

signedto owl

signedout rdfs

setin owl

rdfs alonecomputationally

subset of owl

owl subset

inverse of signedto

inverse property settingfor